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1.0  INTRODUCTION 

This  chapter  explains  the  purpose  of  the  convention,  the  scope  of 
the  guidance,  and  provides  an  explanation  of  how  to  use  the 
convention. 

1.1  PURPOSE  OF  THE  CONVENTION 

The  convention  provides  general  guidance  on  the  implementation 
of  American  National  Standards  Institute  (ANSI)  Accredited  Stand¬ 
ards  Committee  (ASC)  X12  electronic  data  interchange  (EDI) 
standards  within  automated  information  systems  (AIS)  and  infor¬ 
mation  interchange  procedures  that  require  the  collection,  report¬ 
ing,  and/or  exchange  of  data  needed  to  perform  defense  missions. 

1.2  SCOPE 

The  guidance  is  provided  for  two  components.  First,  it  may  be 
used  by  organizational  elements  of  the  DoD  community.  It  may 
also  be  useful  to  organizations  external  to  DoD  that  exchange  data 
with  the  DoD  community  in  the  course  of  their  business  relation¬ 
ships. 

The  DoD  community  encompasses  the  Military  Services,  Organiza¬ 
tions  of  the  Joint  Chiefs  of  Staff,  Unified  and  Specified  Commands, 
Office  of  the  Secretary  of  Defense,  and  the  Defense  agencies.  (That 
community  is  collectively  referred  to  as  the  DoD  Components.) 

Organizational  entities  external  to  DoD  include  (a)  non-Govem- 
ment  organizations,  both  commercial  and  nonprofit;  (b)  Federal 
agencies  of  the  United  States  Government  other  than  DoD; 
(c)  local  and  state  governments;  (d)  foreign  national  governments; 
and  (e)  international  government  organizations. 

The  draft  convention  published  in  this  document  is  for  trial  use 
and  comment.  DoD  Components  must  submit  to  the  DoD  EDI 
Executive  Agent  (EA)  their  data  requirements  that  are  not  covered 
in  the  conventions  as  soon  as  possible,  as  indicated  in  Chapter  2.0, 
Section  2.1. 

1.3  RESPONSIBLE  ENTITY 

The  Defense  Logistics  Agency  (DLA)  is  DoD’s  Executive  Agent 
for  implementing  and  maintaining  Defense-wide  programs  for 
(a)  EDI  in  accordance  with  DepSecDef  memorandum  of  May  24, 
1988,  Subject:  Electronic  Data  Interchange  of  Business-Related 
Transactions;  and  (b)  Protection  of  Logistics  Unclassified/Sensi¬ 
tive  Systems  (PLUS)  in  accordance  with  Assistant' Secretary  of 
Defense  (Production  and  Logistics)  [ASD(P&L)]  memorandum  of 
November  21,  1989,  Subject:  Production  and  Logistics  Task 
Group  for  Data  Protection.  Publication  of  these  conventions  is 
based  upon  this  authority.  See  Chapter  2.0  Maintenance ,  Section  2.1 
for  office  point  of  contact 
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1.4  HOW  TO  USE  THE  IMPLEMENTATION 
CONVENTION 

The  main  topics  and  structures  of  this  document  conform  to  the 
EDI  Implementation  Reference  Manual  Guidelines  document  that 
was  developed  by  a  task  group  of  the  subcommittee  on  education 
and  implementation  of  the  ASC  XI 2.  The  purpose  of  having 
agreed-upon  topics  and  structure  is  to  facilitate  reference  by  the 
many  industry  and  DoD  personnel  who  are  involved  in  implement¬ 
ing  the  uniform  standards  for  electronic  interchange  of  business 
transactions. 

1.4.1  Conventions,  Standards,  and  Guidelines 

The  terms  conventions,  standards,  and  guidelines  are  used 
throughout  the  document  and  are  defined  as  follows: 

•  Conventions  are  the  common  practices  and/or  interpretations 
of  the  use  of  ASC  X12  standards.  Conventions  define  what  is 
included  in  a  specific  implementation  of  an  ASC  X12  standard. 

•  Standards  are  the  technical  documentation  approved  by 
ASC  X12;  specifically,  transaction  sets,  segments,  data  ele¬ 
ments,  code  sets,  and  interchange  control  structure.  Standards 
provide  the  structure  for  each  ASC  X12  document. 

•  Guidelines  are  instructions  on  the  use  of  EDI.  They  provide 
additional  information  to  assist  in  conducting  EDI.  Guidelines 
are  intended  to  provide  assistance  and  should  not  be  your  sole 
source  of  information. 

1 .4.1 .1  Who  Develops  the  Conventions? 

Conventions  result  from  a  joint  effort  between  business,  technical, 
and  EDI  ASC  X12  standards  experts.  The  business  data  require¬ 
ment  is  defined,  a  transaction  set  is  selected,  and  the  data  require¬ 
ment  is  then  identified  with  data  elements  in  the  transaction  set. 
A  convention  is  usually  developed  before  any  computer  EDI  sys¬ 
tems  development  work  and  serves  as  a  design  document  when  the 
development  process  begins. 

1.4.1 .2  Why  Use  a  Convention? 

To  create  an  ASC  X12  transaction,  a  user  must  know  the  data 
requirements,  understand  the  ASC  XI 2  standard,  and  be  able  to 
use  that  information  to  develop  an  interface  program  between  the 
computer  application  and  the  ASC  X12  translator.  The  necessary 
information  to  perform  this  task  is  contained  in  the  convention 
document.  Users  who  follow  the  convention  will  create  a  transac¬ 
tion  set  that  all  DoD  users  understand. 

1.4.1 .3  Who  Needs  a  Convention? 

System  analysts  and  application  programmers  who  plan  to  create 
or  read  ASC  X12  transactions  use  a  convention  to  aid  in  interface 
software  design.  The  convention  will  help  the  programmer  and 
analyst  identify  where  their  application  data  requirement  should  be 
earned  in  an  ASC  X12  transaction  set. 
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1. 4.4.4  Can  I  Develop  a  Convention? 

Conventions  already  exist  for  some  of  the  most  common  business 
practices.  Copies  of  existing  conventions  can  be  acquired  through 
your  organization’s  EDI  coordinator  at  the  start  of  an  EDI  project. 
If  you  find  no  conventions  for  the  business  practice  you  are  about 
to  implement,  your  EDI  coordinator  should  contact  the  DoD  Ex¬ 
ecutive  Agent  for  EDI.  See  Chapter  2.0,  Maintenance ,  Section  2.1 
for  the  point  of  contact. 

1.4.2  Documentation  of  Conventions 

Conventions  are  adopted  from,  and  are  intended  to  be  in  confor¬ 
mance  with,  ANSI  ASC  X12  standards  or  ASC  X12  Draft  Stand¬ 
ards  for  Trial  Use  (DSTU). 

1. 4.2.1  Transaction  Set 

Figure  1.4-1  provides  an  example  of  a  transaction  set  table.  The 
transaction  set  defines  information  of  business  or  strategic  sig¬ 
nificance  and  consists  of  a  transaction  set  header  segment,  one  or 
more  data  segments  in  a  specified  order,  and  a  transaction  set 
trailer  segment.  The  actual  ASC  X12  standard  as  it  appears  in  the 
official  ASC  X12  standards  manual  is  presented  on  the  right  side 
of  the  page.  This  standard  also  includes  both  syntax  notes  and 
comments.  The  specific  DoD  usage  designator  is  presented  on  the 
left  side  of  the  page. 

The  designation  “N/U”  appears  in  the  left  column  if  DoD  does  not 
use  the  specific  segment.  A  page  number  will  appear  if  the  segment 
is  used. 

1. 4.2.2  Transaction  Set  Segment 

Figure  1.4-2  is  an  example  of  a  transaction  set  segment. 

DoD  usage  is  specified  on  the  left  side  of  the  page.  For  identifier 
(ID)  —  type  data  elements,  acceptable  code  values  are  listed  on 
the  right  side  of  the  page  under  the  definitions  of  the  element. 

DoD  notes,  reflecting  how  the  convention  is  to  be  used  appear  on 
the  right  side  of  the  page  at  the  segment  level  or  the  data  element 
level. 

The  following  definitions  are  for  use  in  interpreting  the  data 
element  requirement  designators  in  the  DoD-specific  segment 
directory  section  of  the  convention.  For  ASC  X12  usage,  see  the 
definitions  in  X12.6  Application  Control  Structure. 

•  Mandatory 

Mandatory  data  elements  are  defined  by  ASC  X12. 

•  Optional 

Optional  data  elements  are  used  at  the  discretion  of  the  sending 
party  or  are  based  upon  mutual  agreement  between  trading 
partners. 
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AN-’'  ASC  X12  VERSION/M  LEASE  002010000. 


824  Applk  lion  Advice 

This  standard  provides  the  format  and  establishes  the  data  contents  of  the 
Application  Advice  Transaction  Set  (824)  within  the  context  of  an  Electronic 
Data  Interchange  (EDI)  environment.  This  transaction  set  provides  the  ability 
to  report  the  results  of  an  application  system  s  data  content  edits  of 
transaction  sets.  The  results  of  editing  transaction  sets  can  be  reported  at  the 
functional  group  and  transaction  set  level,  in  either  coded  or  free-form  format. 
It  is  designed  to  accomodate  the  business  need  of  reporting  the  acceptance, 
rejection  or  acceptance  with  change  of  any  transaction  set.  The  Application 
Advice  should  not  be  used  in  place  of  a  transaction  set  designed  as  a 
specific  response  to  another  transaction  set  (e  g.,  purchase  order 
acknowledgement  sent  in  response  to  a  purchase  order). 
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Figure  1.4-1  Example  of  a  Transaction  Set  Table 
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824  ■  APPLICATION  ADVICE 

BCN  •  BEGINNING  SEGMENT  ANSI  ASC  X12  VERSION/RELEASE  003010000 


Mandatory 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 
Syntax: 
Comments: 


BGN  Beginning  Segment 
Header 

Mandatory 

1 

To  indicate  the  beginning  of  a  transaction  set. 

If  BGN05  is  used.  BGN04  is  required. 

7.  BGN02  is  the  Transaction  Set  Reference  Number 

2.  BGN03  is  the  Transaction  Set  Date. 

3.  BGN04  is  the  Transaction  Set  Time. 

4.  BGNOS  is  the  transaction  set  time  qualifier 


Mandatory 


Mandatory 


Conditional 


Not  Uaad 


_ Data  Element  Summary _ 

aar.  data 

»  nor  tea _ ATtapono 

BGNOi  353  Transaction  Sat  Purpose  Coda  M  10  2/2 

Coda  idantifying  purpots  of  transaction  sat. 

00  Original 
01  Cancellation 
04  Change 
12  Not  Processed 

BQN02  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  dsfmed  for  a  particular 
Transaction  Sat,  or  as  specified  by  tha  Rafarsnca  Numbar  Qualifier 

BQN03  373  Data  M  DT  6/6 

Date  (YYMMDD). 

BQN04  337  Time  C  TM  4/4 

Time  expressed  in  24-hour  clock  time  (HHMM.  time  range:  0000  though  2359). 

fmptomenlafton  Note: 

Use  HHMM. 

BGNOS  823  Time  Code  O  ID  2/2 
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Figure  1.4-2  Example  of  a  Transaction  Set  Segment 


BA8EUNE  AS  OF:  JANUARY  »,  IMS 


1.0.5 


nr’ARTMENT  OF  DEFENSE 

DrtAFT  IMPLEMENTATION  CONVENTION 


•  Required 

Required  data  elements  are  considered  optional  under 
ASC  X12  rules,  but  are  required  by  DoD  decision. 

Recommended 

Recommended  data  elements  are  considered  optional  under 
ASC  X12  rules  and  by  the  DoD,  but  the  industry  recommends 
their  use  to  facilitate  EDI.  Most  companies  in  the  industry 
are  expected  to  use  this  data  element. 

•  Not  Used 

“Not  Used’’  data  elements  are  those  that  the  DoD  does  not 
use. 

•  Conditional 

Conditional  data  elements  depend  on  the  presence  of  other  data 
elements  in  the  transaction  set. 
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2.0  MAINTENANCE 

This  chapter  describes  the  procedures  for  maintaining  the  DoD 
conventions.  It  also  presents  a  section  on  version/release  timing. 

2.1  MAINTAINING  CONVENTIONS 

The  DLA.  as  DoD’s  Executive  Agent  for  EDI  and  PLUS,  has 
established  a  joint  program  office  to  oversee  implementation  of 
EDI.  Some  of  the  lunctions  of  this  program  office  are  to  maintain 
configuration  control  of  related  standards  and  common  support 
packages  _(e.g.,  versions  of  ASC  X12  standards  and  PLUS  algo¬ 
rithms  employed),  participate  in  the  standards-setting  process,  and 
ensure  compliance  with  approved  EDI  standards. 

To  accomplish  these  functions,  the  joint  program  office  has  estab¬ 
lished  a  conventions  and  standards  development  and  maintenance 
process  whose  objectives  are:  (1)  to  obtain  ASC  XI 2  data  require¬ 
ments  from  the  DoD  Components  and  present  the  requirements  to 
the  ASC  XI2  for  consideration  as  ANSI  standards,  and  (2)  to 
develop  and  maintain  conventions  for  use  by  DoD  Components 
and  their  potential  trading  partners. 

To  take  advantage  of,  and  not  duplicate,  existing  data  stan¬ 
dardization  processes,  the  EA  has  established  focal  points 
within  the  ASD  Offices,  the  Military  Services,  and  the  Defense 
Agencies  from  which  EDI  information  is  obtained  and  dissemi¬ 
nated. 

The  EA’s  primary  source  of  information  about  DoD’s  data  require¬ 
ments  is  the  EDI  User. 

Changes  to  this  publication  and  recommended  changes  to  ANSI 
ASC  X12  should  be  forwarded  through  your  organizational  point 
of  contact  for  data  standardization  to: 

EDI  Standards  Coordinator 
ATTN:  DLA-ZC 
Cameron  Station 
Alexandria,  VA  22304-6100 

See  Chapter  4  for  reproducible  ASC  X12  Work  Request  forms. 

2.2  VERSION/RELEASE  TIMING 

Identification  of  the  official  “version”  of  a  standard  is  critical  to 
the  successful  interchange  of  information.  Each  participant  must 
be  able  to  send  and  receive  the  same  version  to  ensure  the  accuracy 
of  the  information  exchanged. 

The  version  is  transmitted  as  a  12-character  code  in  the  Functional 
Group  Header  segment  (GS)  in  Data  Element  #480,  Ver¬ 
sion/Release/Industry  ID.  This  12-character  code  is  used  by 
ASC  X12  as  follows: 
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Position 

Content 

1-3 

Version  number 

4-5 

Release  level  of  version 

6 

Subrelease 

7-12 

DoD/Industry  or  Trade  Association  ID 

ASC  X12  assigns  the  codes  in  positions  1  through  6. 

A  major  version  (1-3)  will  change  only  after  an  official  public 
review  cycle,  leading  to  republication  of  a  new  American  National 
Standard. 

Release  level  of  each  new  major  version  (4-6)  will  begin  at  “000” 
and  incremented  by  1  for  each  new  ASC  X12  approved  publication 
cycle,  usually  once  a  year.  The  fifth  character  designates  the 
release  and  the  sixth  character  designates  the  subrelease. 

DoD/Industry/Trade  Association  ID  (7-12)  is  used  to  identify 
conventions.  For  this  suffix,  DoD  will  use  “DoD_”  with  the  10th 
character  identifying  successive  publications.  The  11th  and  12th 
characters  may  be  used  by  the  Military  Departments  or  Defense 
Agencies. 

DoD  conventions  for  using  ASC  X12  standards  are  published 
annually.  Conventions  developed  for  each  release  will  be  main¬ 
tained  for  4  years.  Military  Services  and  DoD  Agencies  will 
determine  which  release  to  use  on  the  basis  of  business  need  but 
will  not  use  any  release  more  than  4  years  old  without  approval 
of  the  DoD  EA. 
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3.0  DoD  CONVENTIONS  FOR  USING 
ASC  X12  TRANSACTION  SETS 


This  chapter  defines  the  DoD  transaction  set  conventions.  It 
includes  the  instructions  for  implementing  the  control  structure  and 
definitions  of  the  usage  indicators  and  applicable  codes. 

3.1  INTRODUCTION 

The  power  of  the  ASC  X12  standard  is  in  its  building  block 
concept,  which  standardizes  the  essential  elements  of  business 
transactions.  It  is  analogous  to  a  “standard  bill  of  materials  and 
the  construction  specifications,”  which  gives  the  architect 
flexibility  in  what  can  be  designed  with  standardized  materials  and 
procedures.  The  EDI  system  designer,  like  the  architect,  uses  the 
ASC  X12  standards  to  build  business  transactions  that  are  often 
different  because  of  their  function  and  yet  utilize  the  ASC  X12 
standards.  The  “bill  of  materials  and  the  construction  specification” 
of  ASC  X12  are  the  standards  found  in  the  published  technical 
documentation. 

ASC  X12.3  -  The  Data  Element  Dictionary  specifies  the  data 
elements  used  in  the  construction  of  the  segments  that  comprise 
the  transaction  sets  developed  by  ASC  XI 2. 

ASC  X12.5  -  The  Interchange  Control  Structure  provides  the 
interchange  control  segment  (also  called  an  envelope)  of  a  header 
and  trailer  for  the  electronic  interchange  through  a  data  transmis¬ 
sion;  it  also  provide  a  structure  to  acknowledge  the  receipt  and 
processing  of  the  envelope. 

ASC  X12.6  -  The  Application  Control  Structure  defines  the  basic 
control  structures,  syntax  rules,  and  semantics  of  EDI. 

ASC  X12.22  -  The  Data  Segment  Directory  provides  the  defini¬ 
tions  and  specifications  of  the  segments  used  in  the  construction 
of  transaction  sets  developed  by  ASC  XI 2. 

The  DoD  convention  in  Section  3.4  conform  to  the  above  standards 
and  each  transaction  set  is  a  complete  document  to  the  extent 
possible.  For  further  clarification  of  acronyms,  abbreviations,  and 
codes,  refer  to  ASC  X12  published  technical  documentation.  Con¬ 
tact  the  DoD  EDI  Executive  Agent  for  copies  or  the  Data  Inter¬ 
change  Standards  Association,  Inc.,  Suite  355,  1800  Diagonal 
Road,  Alexandria,  VA  22314. 

3.2  CONTROL  SEGMENTS 

In  addition  to  the  communication  control  structure,  the  EDI  structure 
provides  the  standards  user  with  multiple  levels  of  control  to  ensure 
data  integrity.  It  does  so  by  using  header  and  trailer  control  segments 
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designed  to  identify  uniquely  the  start  and  end  of  the  interchange 
functional  groups  and  transaction  sets.  The  relationship  of  these 
control  segments  is  shown  in  Figure  3.2-1.  Control  Segment 
specifications  are  defined  in  Section  3.2.2. 

3.2.1  Description  of  Use 

The  interchange  header  and  trailer  segments  surround  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions: 

•  Define  the  data  element  separators  and  data  segment  ter¬ 
minators 

•  Identify  the  sender  and  receiver 

•  Provide  control  information 

•  Allow  for  authorization  and  security  information. 

The  Interchange  Acknolwedgment  Segment  is  used  to  acknowledge 
one  interchange  header  and  trailer  envelope  where  the  envelope 
surrounds  one  or  more  functional  groups.  (No  acknowledgment  is 
made  for  the  interchange  acknowledgment.) 

The  interchange  control  number  value  in  the  acknowledgment 
(TA1  segment)  is  the  same  as  that  for  the  ISA  segment  that  is 
being  acknowledged.  The  control  number  serves  as  a  link  between 
the  interchange  header  and  trailer  and  the  acknowledgment  of  that 
header  and  trailer. 

The  interchange  acknowledgment  does  not  report  any  status  on  the 
functional  groups  contained  in  the  interchange  and  is  separate 
from  the  communication  system’s  error  procedures. 

The  preparer  of  the  interchange  header  and  trailer  indicates  the 
level  of  acknowledgment  in  Data  Element  113,  Acknowledgment 
Requested.  If  an  acknowledgment  is  requested,  then  the  recipient 
must  return  an  acknowledgment.  If  not  requested,  none  should  be 
given. 

The  interchange  acknowledgment  control  segments  are  placed  after 
the  interchange  header  and  before  the  first  functional  group  or 
before  the  interchange  trailer  if  there  are  no  functional  groups. 

Control  segments  are  standard  for  all  implementation  conventions 
produced  for  the  Department  of  Defense.  Some  codes  associated 
with  individual  data  elements  within  the  control  segments  are 
unique  to  the  individual  transaction  set.  Others,  identify  the  ANSI 
version  and  release  in  which  the  convention  is  written. 
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Figure  3.2-1.  Hierarchical  Structure 
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Code  Value  Implementation  Note: 

An  agreed  upon  designation  of  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  (VAN). 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


ISA08  107  Interchange  Receiver  ID  M  ID  15/15 

Identification  code  published  by  the  receiver  of  the  data.  When  sending,  it  is 
used  by  the  sender  as  their  sending  ID,  thus  other  parties  sending  to  them  will 
use  this  as  a  receiving  ID  to  route  data  to  them. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 

ISA39  108  Interchange  Date  M  DT  6/6 

Date  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  YYMMDD 

ISA10  109  Interchange  Time  M  TM  4/4 

Time  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  HHMM 

ISA11  110  Interchange  Control  Standards  Identifier  M  ID  1/1 

Code  to  identify  the  agency  responsible  for  the  control  standard  used  by  the 
message  that  is  enclosed  by  the  interchange  header  and  trailer. 

U  U.S.  EDI  Community  of  ASC  XI 2,  TDCC,  and  UCS 

ISA  12  111  Interchange  Control  Version  Number  M  ID  5/5 

This  version  number  covers  the  interchange  control  segments  and  the  functional 
group  control  segments. 

00302  Draft  Standard  for  Trial  Use  Approved  for  Publication  by  ASC  XI 2  Procedures 
Review  Board  Through  October  1991 

Code  Value  Implementation  Note: 

Version  ID  as  defined  or  agreed  upon  by  the  trading  partners. 

ISA13  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

ISA14  113  Acknowledgment  Requested  M  ID  1/1 

Code  sent  by  the  sender  to  request  an  interchange  acknowledgment. 

0  No  Acknowledgment  Requested 
1  Interchange  Acknowledgment  Requested 

ISA15  114  Test  Indicator  M  ID  1/1 

Code  to  indicate  whether  data  enclosed  by  this  interchange  envelope  is  test  or 
production. 

P  Production  Data 
T  Test  Data 
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Segment:  GS  Functional  Group  Header 

Purpose:  To  indicate  the  beginning  of  a  functional  group  and  to  provide  control 
information 


Syntax:  The  data  interchange  control  number  (GS06)  in  this  header  must  be 
identical  to  the  same  data  element  in  the  associated  Functional  Group 
Trailer  (GE02). 

Comment:  A  functional  group  of  related  transaction  sets,  within  the  scope  of  XI 2 

standards,  consists  of  a  collection  of  similar  transaction  sets  enclosed  by 
a  functional  group  header  and  a  functional  group  trailer. 


i 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

OES.  ELEMENT  NAME _ ATTRIBUTES 

GS01  479  Functional  Identifier  Code  M  ID  2/2 

Code  identifying  a  group  of  application  related  Transaction  Sets. 

Implementation  Note: 

Choose  the  code  value  appropriate  to  the  information  content  of  the  functional  group.  See  X 12  Dictionary  for 
source  code  list. 

TD  Trading  Partner  Profile  (838) 

GS02  142  Application  Sender’s  Code  M  AN  2/15 

Code  identifying  party  sending  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  Recommend  for  increased  security  that  non-DoD  code  differ 
from  that  used  in  ISA06. 

GS03  124  Application  Receiver’s  Code  M  AN  2/15 

Code  identifying  party  receiving  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  (DoDAAC ).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  Recommend  for  increased  security  that  non-DoD  code  differ 
from  that  used  in  1SA08. 

GS04  29  Group  Date  M  DT  6/6 

Date  sender  generated  a  functional  group  of  transaction  sets. 

Implementation  Note: 

Assigned  by  translation  software. 

GS05  30  Group  Time  M  TM  4/4 

Time  (HHMM)  when  the  sender  generated  a  functional  group  of  transaction  sets 
(local  time  at  sender's  location). 

Implementation  Note: 

Assigned  by  translation  software. 


Mandatory 


GS06  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 
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Implementation  Note: 

Assigned  by  translation  software. 


001  'CONTROL  SEGMENTS 
GS  •  FUNCTIONAL  GROUP  HEADER 


Mandatory 


Mandatory 


GS07  455  Responsible  Agency  Code  M  ID  1/2 

Code  used  in  conjunction  with  Data  Element  480  to  identify  the  issuer  of  the 
standard. 

X  Accredited  Standards  Committee  XI 2 

Code  Value  Implementation  Note: 

Indicates  that  an  ANSI  XI 2  standard  is  being  transmitted. 


GS08  480  Version/Release/Industry  ID  Code  M  ID  1/12 

Code  indicating  the  version,  release,  subrelease  and  industry  identifier  of  the  EDI 
standard  being  used.  Positions  1-3,  version  number;  positions  4-6,  release  and 
subrelease  level  of  version;  positions  7-12,  industry  or  trade  association  identifier 
(optionally  assigned  by  user). 

003020  Draft  Standards  Approved  By  ASC  XI 2  Through  June  1991. 

Code  Value  Implementation  Note: 

Code  value  agreed  to  by  trading  partners.  See  XI2  Dictionary  for  source  code  list. 
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Segment:  IEA  Interchange  Control  Trailer 

Purpose:  To  define  the  end  of  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

OES,  ELEMENT  NAME _ ATTRIBUTES 

IEA01  116  Number  of  Included  Functional  Groups  M  NO  1/5 

A  count  of  the  number  of  functional  groups  included  in  a  transmission. 

Implementation  Note: 

Assigned  by  translation  software. 

IEA02  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  number  must  match  the  number  that  occurs  in  ISA13. 
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EXAMPLE  ■  TRADING  PARTNER  PROFILE-REGISTRATION  (838  R) 


ASCX12  EDI  FORMAT  DEFINITION 

ST*838*R1000  N/L  THIS  IS  AN  838  REGISTRATION  TRANSACTION  SET 

TRANSACTION  SET  WITH  A  CONTROL 
NUMBER  OF  R1000 

BTP*00*REGO0 1*9301 28*0900*TP*3  5  N/L  AN  ORIGINAL  REGISTRATION  WITH  A  REFERENCE 

NUMBER  OF  REG001  CREATED  ON  JANUARY  28,  1993 
AT  9  A.M..  THIS  IS  AN  INITIAL  REGISTRATION. 

PL  A*  1  *SE*93020 1  N/L  AN  INITIAL  REGISTRATION  FROM  A  VENDOR  WITH 

AN  EFFECTIVE  DATE  OF  1  FEBRUARY  1993. 

THE  FIRST  INTERATTON  OF  THE  LCD  SEGMENT 
INDICATES  THAT  THE  REGISTRATION  IS  FROM  A 
DEALER. 

THE  SECOND  ITERATION  OF  THE  LCD  SEGMENT 
INDICATES  THE  DEALER  IS  A  SMALL 
DISADVANTAGED  BUSINESS. 

THE  THIRD  ITERATION  OF  THE  LCD  SEGMENT 
INDICATES  THE  DEALER  IS  A  SECTION  (8a) 
PROGRAM  PARTICIPANT. 

THE  FOURTH  ITERATION  OF  THE  LCD  SEGMENT 
INDICATES  THE  DEALER  IS  LOCATED  IN  A  LABOR 
SURPLUS  AREA. 

N1*ZZ*J.C.  SMITH.  INC.*33*1B712  N/L  THE  COMPANY'S  NAME  IS  J.C.  SMITH.  INC.  AND  IT 

HAS  A  CAGE  CODE  OF  1B712. 

N3*  1 352  N.  HAMPTON  STREET  N/L  COMPANY'S  STREET  ADDRESS. 

N4*CHICAGO*IL*60623-1600  N/L  THE  COMPANY  IS  LOCATED  IN  CHICAGO.  EL  WITH  A 

ZIP  CODE  OF  60623-1600. 


LCD*1*DLN/L 


LCD*2*27  N/L. 


LCD*3*30  N/L 


LCD*4*26  N/L 
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N9*TJ*A  1 B2C3  N/L  THE  REGISTERING  PARTY'S  TAX  PAYER'S  NUMBER 

IS  A1B2C3 . 

PER*IC*MARTIN  JONES  *TE*3 127345796  N/L  COMPANY'S  POINT  OF  CONTACT  IS  MARTIN  JONES 

WHOSE  TELEHONE  NUMBER  IS  312-734-5796. 

TPD*S*Z*12345*PRIMARY  N/L  THE  COMPANY  HAS  A  SIC  CODE  OF  12345  WHICH  IS 

A  PRIMARY  CODE 

PAM*01*125*EA  N/L  THE  COMPANY  HAS  125  EMPLOYEES. 

SE*15*R1000  N/L  THE  TRANSACTION  HAS  15  SEGMENTS  AND  THE 

CONTROL  NUMBER  IS  R1000. 


NOTE:  ALL  NUMBERS  ARE  NOTIONAL  AND  USED  FOR  ILLUSTRATION  PURPOSES  ONLY. 
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838  Trading  Partner  Profile 

This  standard  provides  the  format  and  establishes  the  data  contents  of  the 
Trading  Partner  Profile  Transaction  Set  within  the  context  of  an  Electronic 
Data  Interchange  (EDI)  environment.  This  transaction  set  can  be  used  to 
request,  change,  verify  or  transmit  business  profile  information  to  or  from  a 
trading  partner.  This  information  can  be  used  by  the  receiver  to  facilitate  the 
processing  of  the  sender's  business  transactions. 


The  transaction  set  may  be  used  to  convey  government  survey  information, 
business  classification,  general  survey  information,  summary  supplier 
ratings  changes  in  the  EDI  environment  information,  tax  information,  entity 
relationships,  and  general  business  profile  information  to  update  automated 
information  databases  between  trading  partners. 


Table  1 


PAGE*  POS. * 

SEG.ID 

NAME 

REQ.  DES. 

MAX  USE 

LOOP  REPEAT 

4 

rrm 

ST 

Transaction  Set  Header 

M 

i 

5 

1 

BTP 

Beginning  Segment  For  Trading  Partner  Profile 

M 

i 

LOOP  ID- PLA 

>1 

7 

030 

PLA 

Place  or  Location 

M 

i 

8 

LCD 

Place/Location  Description 

O 

>i 

N/U 

1 

LIN 

Item  Identification 

O 

>i 

LOOP  ID -N1 

>1 

10 

060 

N1 

Name 

M 

i 

12 

070 

N2 

Additional  Name  Information 

0 

2 

13 

080 

N3 

Address  Information 

0 

2 

14 

090 

N4 

Geographic  Location 

0 

1 

15 

100 

N9 

Reference  Number 

0 

>1 

16 

110 

PER 

Administrative  Communications  Contact 

0 

>1 

N/U 

120 

CUR 

Currency 

0 

>1 

N/U 

130 

TAX 

Tax  Reference 

0 

>1 

N/U 

140 

FOB 

F.O.B.  Related  Instructions 

0 

>1 

N/U 

150 

ITD 

Terms  of  Sale/Deferred  Terms  of  Sale 

0 

>1 

N/U 

160 

TD5 

Carrier  Details  (Routing  Sequence/T ransit 
Time) 

0 

>1 

N/U 

170 

FBB 

Foreign  and  Industry  Business 

0 

>1 

LOOP©- TPD 

:  V:  >1 

18 

180 

TPD 

Trading  Partner  Detail 

0 

1 

N/U 

190 

N9 

Reference  Number 

0 

>1 

N/U 

200 

PID 

Product/Item  Description 

0 

>1 

1 
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N/U 

210 

DTM 

Date/Time  Reference 

0 

>1 

LOOP  ID  -  TUD 

>1 

N/U 

220 

TUD 

Trade  Union  Data 

o 

1 

N/U 

230 

DTM 

Date/Time  Reference 

0 

>1 

N/U 

240 

N1 

Name 

0 

1 

N/U 

250 

N2 

Additional  Name  Information 

0 

2 

N/U 

260 

N3 

Address  Information 

0 

2 

N/U 

270 

N4 

Geographic  Location 

0 

1 

N/U 

280 

PER 

Administrative  Communications  Contact 

0 

>1 

LOOP  ID -SPR 

1111: m 

N/U 

290 

SPR 

Supplier  Rating 

0 

1 

N/U 

300 

N9 

Reference  Number 

0 

>1 

N/U 

310 

DTM 

Date/Time  Reference 

0 

>1 

LOOP  ID*  PAM 

>1 

19 

320 

PAM 

Period  Amount 

0 

1 

N/U 

330 

DTM 

Date/Time  Reference 

0 

>1 

N/U 

340 

TAX 

Tax  Reference 

0 

>1 

N/U 

350 

CUR 

Currency 

0 

>1 

LOOP  ID* TXN 

>1 

N/U 

360 

TXN 

Transaction  Capabilities 

0 

1 

N/U 

370 

N9 

Reference  Number 

o 

>1 

N/U 

380 

DTM 

Date/Time  Reference 

o 

>1 

HMl 

>1 

N/U 

390 

ENE 

Electronic  Systems  Environment 

0 

1 

LOOP  ID -N1 

>1 

N/U 

400 

N1 

Name 

0 

1 

N/U 

410 

N2 

Additional  Name  Information 

0 

2 

N/U 

420 

N3 

Address  Information 

0 

2 

N/U 

430 

N4 

Geographic  Location 

0 

1 

N/U 

440 

TPD 

Trading  Partner  Detail 

o 

>1 

N/U 

450 

PID 

Product/Item  Description 

0 

>1 

N/U 

460 

N9 

Reference  Number 

0 

>1 

N/U 

470 

PER 

Administrative  Communications  Contact 

0 

>1 

LOOP  ID -TXN 

.  ■  .  m  •  • 

N/U 

480 

TXN 

Transaction  Capabilities 

o 

1 

N/U 

490 

N9 

Reference  Number 

0 

>1 

N/U 

500 

DTM 

Date/Time  Reference 

0 

>1 

N/U 

510 

ERI 

Entity  Relationship 

0 

>1 

N/U 

520 

AMT 

Monetary  Amount 

0 

>1 

21 

530 

SE 

Transaction  Set  Trailer 

M 

1 

NOTE: 

1/170 
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DRAFT  IMPLEMENTATION  CONVENTION 


836  •  REGISTRATION 

BTP  •  BEGINNING  SEGMENT  FOR  TRADING  PARTNER  PROFILE  ANSI  ASC  X12  VERSION/RELEASE  003020DOD_ 


Mandatory 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 
Syntax: 

Comments: 


BTP  Beginning  Segment  For  Trading  Partner  Profile 

Header 


Mandatory 

1 

To  indicate  the  type  and  purpose  of  the  profile  data 

1.  C0807  —  If  BTP08  is  present,  then  BTP07  is  required. 

2.  C0908  —  If  BTP09  is  present,  then  BTP08  is  required. 

1.  BTP01  indicates  the  purpose  of  this  EDI  transmission. 

2.  BTP02  is  the  identifying  number  of  this  transaction. 

3.  BTP03  and  BTP04  are  the  transaction  set  date  and  time. 

4.  BTP06  indicates  the  status  of  the  data  content  within  the  transaction. 

5.  BTP07  indicates  reference  number  or  previous  reference  number 
associated  with  this  transaction. 

6.  BTP08  and  BTP09  are  date  and  time  associated  with  BTP07. 


Mandatory 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

DCS,  ELEMENT  NAME _ ATTWEUTES 

BTP01  353  Transaction  Set  Purpose  Code  M  ID  212 

Code  identifying  purpose  of  transaction  set. 

00  Original 
01  Cancellation 
02  Add 
03  Delete 
04  Change 
07  Duplicate 

BTP02  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Implementation  Note: 

Assigned  by  the  originator  of  the  transaction  set.  In  this  context,  assign  a  unique  reference  number  that  can 
be  cross-referenced  in  any  subsequent  transaction. 

BTP03  373  Date  M  DT  6/6 

Date  (YYMMDD). 

Implementation  Note: 

Date  the  transaction  was  created. 


Mandatory 


BTP04  337  Time  M  TM  4/6 

Time  expressed  in  24-hour  clock  time  (HHMMSS)  (Time  range:  000000  through 
235959) 

Implementation  Note: 

Time  the  transaction  was  created.  Use  HHMM. 
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836  •  REGISTRATION 

ANSI  ASC  X12  VERSION/RELEASE  003020DOD_  BTP  •  BEGINNING  SEGMENT  FOR  TRADING  PARTNER  PROFILE 


Mandatory 


Mandatory 


Not  Used 
Not  Used 
Not  Used 


BTP05  640  Transaction  Type  Code  M  ID  212 

Code  specifying  the  type  of  transaction. 

TP  Trading  Partner  Information 

BTP06  353  Transaction  Set  Purpose  Code  M  ID  2/2 

Code  identifying  purpose  of  transaction  set. 

Implementation  Note: 

Use  code  04  when  requesting  a  change  to  data  previously  submitted ;  use  code  13  when  requesting  a  change 
to  a  previously  issued  password;  use  code  27  to  verify  a  password;  use  code  30  for  annual  renewal;  use  code 
35  when  making  an  initial  registration. 

04  Change 
13  Request 
27  Verify 
30  Renewal 
35  Request  Authority 


BTP07 

127 

Reference  Number 

C 

AN 

1/30 

BTP08 

373 

Date 

C 

DT 

6/6 

BTP09 

337 

Time 

O 

TM 

4/6 

DC03  •  JANUARY  29  1993 
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ANSI  A  SC  X12  VERSION/RELEASE  003020DOD 


Optional 


Segment:  LCD  Place/Location  Description 
Level:  Header 
Loop:  PLA 
Usage:  Optional 
Max  Use:  >1 


838  •  REGISTRATION 
LCD  •  PLACE/LOCATION  DESCRIPTION 


Purpose:  To  further  define  and  describe  a  place  or  location 
Syntax:  P0506  —  If  either  LCD05  or  LCD06  is  present,  then  the  other  is  required. 
Implementation  Note: 

At  least  one  iteration  of  the  LCD  segment  is  required  when  BTP06  is  either  code  "30"  or  code  "35". 


Mandatory 


_ Data  Element  Summary _ 

RE  f.  DATA 

OSS.  ElEMEKT  UAHS _ ATTRIBUTES 

LCD01  350  Assigned  Identification  M  AN  1/11 

Alphanumeric  characters  assigned  for  differentiation  within  a  transaction  set. 

Implementation  Note: 

A  unique  number  assigned  by  the  orginator  of  the  transaction  set. 


Optional 


LCD02  98  Entity  Identifier  Code  O  ID  2/2 

Code  identifying  an  organizational  entity  or  a  physical  location. 

Implementation  Notes: 

1.  At  least  one  iteration  is  required  for  initial  registration  and  annual  updates.  In  the  first  iteration,  there 
must  be  one  of  the  following  codes:  MF.  DL,  DS,  SJ,  13.  SC,  or  22.  In  succeeding  optional  iterations,  any  of 
tne  following  applicable  codes  can  be  used:  24,  RL,  VN,  M8,  26,  SN,  30,  or  27.  If  code  30  is  used,  do  not  use 
code  27  and  vice  versa:  they  are  mutually  exclusive. 

2.  Use  as  many  iterations  of  LCD  as  necessary  to  describe  your  business  entity.  Use  code  M8  to  denote  an 
institution  that  is  an  historically  Black  College  or  University:  use  code  13  for  a  service  company:  use  code  24 
to  indicate  a  Woman-owned  Business;  use  code  26  to  indicate  a  Labor  Surplus  Area  Firm;  use  code  27  to 
indicate  an  other  Disadvantaged  Business;  use  code  RL  to  indicate  a  Veteran-owned  Business;  use  code  30 
for  a  Section  8( a)  Program  Participant  firm;  use  code  SN  to  indicate  Sheltered  Workshop;  use  code  VN  to 
indicate  an  Educational  or  nonprofit  Institution;  use  code  SC  for  Sales  Office;  use  code  SJ  for  Construction ; 
use  code  72.  for  an  other  type  of  firm. 

3.  When  LCD02  is  code  22.  use  the  TPD  segment  to  describe  the  firm. 

13  Contracted  Service  Provider 
24  Woman-Owned  Business,  Small 

26  Socially  Disadvantaged  Business 

27  Small  Disadvantaged  Business 
30  Service  Supplier 

DL  Dealer 
DS  Distributor 
M8  Educational  Institution 
MF  Manufacturer  of  Goods 
RL  Reporting  Location 
SC  Store  Class 
SJ  Service  Provider 
SN  Store 
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LCD  •  PLACE/LOCATION  DESCRIPTION _ ANSI  ASC  X12  VERSION/RELEASE  003020DQD 

VN  Vendor 
ZZ  Mutually  Defined 


Not  Used 

LCD03 

306 

Action  Code 

O 

ID 

1/1 

Not  Used 

LCD04 

373 

Date 

0 

DT 

6/6 

Not  Used 

LCD05 

66 

Identification  Code  Qualifier 

C 

ID 

1/2 

Not  Used 

LCD06 

67 

Identification  Code 

C 

AN 

2/17 
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838  •  REGISTRATION 

ANSI  ASC  X12  VERSION/RELEASE  003020DOD_ _ N1  •  NAME 


Mandatory 


Segment:  N1  Name 
Level:  Header 
Loop:  N1  Repeat:  >1 
Usage:  Mandatory 
Max  Use:  1 

Purpose:  To  identify  a  party  by  type  of  organization,  name  and  code 

Syntax:  1.  R0203  —  At  least  one  of  N1 02  or  N1 03  is  required. 

2.  P0304  —  If  either  N1 03  or  N1 04  is  present,  then  the  other  is  required. 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  "ID 
Code"  (N104)  must  provide  a  key  to  the  table  maintained  by  the 
transaction  processing  party. 


Implementation  Note: 

At  least  one  iteration  of  the  N1  loop  is  required  to  convey  the  address  of  the  registering  party. 


Mandatory 


Required 


Conditional 


Conditional 


_ Data  Element  Summary _ 

REF.  DATA 

DES. _ ELEMENT  NAME _ ATTRIBUTES 

N101  98  Entity  Identifier  Code  M  ID  2/2 

Code  identifying  an  organizational  entity  or  a  physical  location. 

Implementation  Notes: 

1.  Code  ZZ  is  the  registering  party;  therefore,  there  must  be  at  least  one  iteration  of  the  N1  loop  using  code 
ZZ  in  N 101.  Use  code  CQ  in  lieu  of  code  ZZ  when  firm  is  a  parent . 

2.  If  registering  party  is  a  subsidiery,  use  code  SI  to  provide  the  name  of  the  parent  company.  If  registering 
parly  has  currently  afflialed  firms,  use  code  CF  to  identify  them.  Use  code  SN  to  identify  all  previously 
affliated  firms.  If  registering  party  has  operated  under  other  names,  use  code  PS  to  provide  them. 

CF  Subsidiary/Division 
CQ  Corporate  Office 

PS  Previous  Station 

Si  Parent 

SN  Store 

ZZ  Mutually  Defined 


N102 

93 

Name 

Free-form  name. 

C 

AN 

1/35 

N103 

66 

Identification  Code  Qualifier 

C 

ID 

1/2 

Code  designating  the  system/method  of  code  structure  used  for  Identification 
Code  (67). 


Implementation  Note: 

In  addition  to  providing  long-line  address  information,  NI03  will  be  used  if  the  company  has  a  permanent 
CAGE  code  assigned.  Use  code  33  and  carry  the  actual  code  in  NI04.  Otherwise,  leave  blank. 

33  Commercial  and  Government  Entity  (CAGE) 

N104  67  Identification  Code  C  AN  2/17 

Code  identifying  a  party. 


OC03  •  JANUARY  29  1993 
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Implementation  Note: 

The  CAGE  code. 
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838  •  REGISTRATION 

N3  ■  ADDRESS  INFORMATION _ ANSI  ASC  X12  VERSION/RELEASE  003020PQD_ 

Segment:  N3  Address  information 
Level:  Header 


Optional 


Loop:  N1 
Usage:  Optional 
Max  Use:  2 

Purpose:  To  specify  the  location  of  the  named  party 


Implementation  Note: 

Required  for  the  registering  party  when  N101  is  code  CQ  or  22  and  BTP06  is  code  30,  code  35,  or 
code  04  (if  the  change  affects  the  N1  segment).  Also  required  for  any  other  ftrm(s)  named  at 
N 101/ 102  under  the  same  condition. 


Mandatory 

Optional 


Data  Element  Summary 


IMP. 

DCS. 

DATA 

CLEMENT 

NAME 

ATTRIBUTES 

N301 

166 

Address  information 

Address  information 

M 

AN 

1/35 

N302 

166 

Address  Information 

Address  information 

O 

AN 

1/35 
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838  •  REGISTRATION 
N9  •  REFERENCE  NUMBER 


Optional 


Segment:  N9  Reference  Number 
Level:  Header 
Loop:  N1 
Usage:  Optional 
Max  Use:  >1 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  A  SC  X12  VERSION/RELEASE  003020DOD_ 


Purpose:  To  transmit  identifying  numbers  and  descriptive  information  as  specified 
by  the  reference  number  qualifier 

Syntax:  R0203  —  At  least  one  of  N902  or  N903  is  required. 

Implementation  Note: 

Only  one  iteration  of  the  N9  segment  will  be  used.  Required  only  if  the  registering  party  has  a  tax 
payers  number. 


Mandatory 


Conditional 


Not  Used 
Not  Usad 
Not  Uaad 


_ Data  Element  Summary _ 

REF.  DATA 

DES.  ELEMENT  NAME _ ATHWRUTES 

N901  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

Implementation  Note: 

The  taxpayer’s  identification  number  is  only  required  for  the  registering  party,  not  for  other  entities  such  as 
the  registering  party's  parent  company  or  affliated  companies,  etc. 

TJ  Federal  Taxpayer's  Identification  Number 

N902  127  Reference  Number  C  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 


N903 

369 

Free-form  Description 

C 

AN 

1/45 

N904 

373 

Date 

O 

DT 

6/6 

N905 

337 

Time 

O 

TM 

4/6 
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838  *  REGISTRATION 

PER  •  ADMINISTRATIVE  COMMUNICATIONS  CONTACT  ANSI  ASC  X12  VERSION/RELEASE  003020DOD 

| 

Implementation  Note: 

If  the  Electronic  Mail  Address  is  greater  than  25  characters,  repeat  the  PER  segment  to  pick  up  the 
remaining  characters. 
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Optional 


Segment:  TPD  Trading  Partner  Detail 
Level:  Header 
Loop:  TPD  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 


838  •  REGISTRATION 
TPD  •  TRADING  PARTNER  DETAIL 


Purpose:  To  describe  attribute  of  a  trading  partner 
Syntax:  P0203  —  If  either  TPD02  or  TPD03  is  present,  then  the  other  is  required. 
Implementation  Note: 

When  BTP06  is  code  30  or  35,  at  least  one  iteration  of  this  segment  is  required  to  pass  SIC  code 
information. 


Mandatory 


Conditional 


Conditional 


_ Data  Element  Summary _ 

REF.  OAT* 

DES.  ELEMENT  NAME _ ATTRIBUTES 

TPD01  349  Item  Description  Type  M  ID  1/1 

Code  indicating  the  format  of  a  description. 

Implementation  Note: 

Use  code  F  when  LCD02  is  code  72  and  describe  the  firm  in  TPD04.  Use  code  S  when  listing  and  describing 
SIC  codes. 


F  Free-form 

S  Structured  (From  Industry  Code  List) 

TPD02  23  Commodity  Code  Qualifier  C  ID  1/1 

Code  identifying  the  commodity  coding  system  used  for  Commodity  Code. 

Implementation  Note: 

Use  to  indicate  Standard  Industrial  Classification  (SIC)  Code  to  follow. 

Z  Mutually  defined. 

TPD03  22  Commodity  Code  C  AN  1/16 

Code  describing  a  commodity  or  group  of  commodities. 

Implementation  Note: 

SIC  Code- 


Optional 


TPD04  352  Description  O  AN  1/80 

A  free-form  description  to  clarify  the  related  data  elements  and  their  content. 

Implementation  Notes: 

1.  If  registrant  deals  in  all  SIC  codes,  insert  an  F  in  TPD01  and  the  phrase  ALL  in  TPD04. 

2.  For  each  SIC  Code  listed  in  every  iteration  of  data  element  TPD03.  differentiate  between  primary  (P)  and 
other  (O)  for  the  code. 

3.  If  LCD02  is  code  72  and  TP  DO  l  is  code  F,  describe  the  type  of firm. 

4.  When  BTP06  is  code  30  or  35,  at  least  one  iteration  orthis  data  element  is  required  to  pass  SIC 
codeinformation . 
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838  •  REGISTRATION 
PAM  •  PERIOD  AMOUNT 


Optional 


Segment:  PAM  Period  Amount 
Level:  Header 
Loop:  PAM  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003020DOD_ 


Purpose:  To  indicate  a  quantity  and/or  amount  for  an  identified  period 
Syntax:  1.  R0205  —  At  least  one  of  PAM02  or  PAM05  is  required. 

2.  C020103  —  If  PAM02  is  present,  then  PAM01  and  PAM03  are 
required. 

3.  P0405  —  If  either  PAM04  or  PAM05  is  present,  then  the  other  is 
required. 

4.  P0607  —  If  either  PAM06  or  PAM07  is  present,  then  the  other  is 
required. 

5.  L070809  —  If  PAM07  is  present,  then  at  least  one  of  PAM08  or 
PAM09  are  required. 

6.  C0807  —  If  PAM08  is  present,  then  PAM07  is  required. 

7.  C0907  —  If  PAM09  is  present,  then  PAM07  is  required. 

8.  LI  01 1 12  —  If  PAM10  is  present,  then  at  least  one  of  PAM1 1  or 
PAM  12  are  required. 

9.  Cl  1 1 0  —  If  PAM1 1  is  present,  then  PAM1 0  is  required. 

10.  P1314  —  If  either  PAM13  or  PAM14  is  present,  then  the  other  is 
required. 

Semantic:  PAM1 0,  PAM1 1 ,  or  PAM1 2  are  used  when  two  dates  are  required. 
Implementation  Note: 

When  BTP06  is  code  30  or  35,  thet  e  must  be  at  least  one  iteration  of  the  PAM  segment  to  provide 
the  total  number  of  employees. 


Conditional 


Conditional 


Conditional 


Not  Used 


Data  Element  Summary 

DATA 

ELEMENT 

NAME 

ATTRIBUTES 

PAM01 

673 

Quantity  Qualifier 

Code  specifying  the  type  of  quantity. 

C 

ID 

212 

01  Discrete  Quantity 

Code  Value  Implementation  Note: 

Use  code  01  to  represent  employee  total. 

PAM02 

380 

Quantity 

Numeric  value  of  quantity. 

C 

R 

1/15 

PAM03 

355 

Unit  of  Measurement  Code 

Code  identifying  the  basic  unit  of  measurement. 

C 

ID 

2/2 

EA  Each 

PAM04 

522 

Amount  Qualifier  Code 

C 

ID 

1/2 
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838  -  REGISTRATION 

SE  •  TRANSACTION  SET  TRAILER 


Mandatory 


Segment:  SE  Transaction  Set  Trailer 
Level:  Header 

Loop:  _ 

Usage:  Mandatory 
Max  Use:  1 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 

ANSI  ASC  X12  VERSION/RELEASE  003020DOD_ 


Purpose:  To  indicate  the  end  of  the  transaction  set  and  provide  the  count  of  the 
transmitted  segments  (including  the  beginning  (ST)  and  ending  (SE) 
segments). 


Comment:  SE  is  the  last  segment  of  each  transaction  set. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

OES.  ELEMENT  NAME _ ATTRIBUTES 

SE01  96  Number  of  Included  Segments  M  NO  1/6 

Total  number  of  segments  included  in  a  transaction  set  including  ST  and  SE 
segments. 

SE02  329  Transaction  Set  Control  Number  M  AN  4/9 

Identifying  control  number  assigned  by  the  originator  for  a  transaction  set. 


Implementation  Note: 

This  is  the  same  number  as  the  one  in  ST02. 
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ASC  X  12  FORMS 


In  this  chapter,  applicable  ASC  X12  forms  are  presented. 


BASELINE  AS  OF:  JANUARY  29, 1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


XtMMA  MP0RMA7BN  MANUAL 


VIII  -  FORMS,  FORMS,  FORMS 


ASC  X12  Work  Roque*  Form 

ASC  X12  Now  Project  Proposal  Form 

ASC  X12  Now  Transaction  Sot  Development  Form 

Form  lor  Now  or  Revised  Append*  A  Codo  Sourco  Reference 

Oocumont  Preparation  for  Interpretations,  Guidelines  and  Control  Standards 

Sample  Transmeta!  Form 

ASC  X12  Balot  Common!  Response  Lottor  Formal 
ASC  X12  Standardo  Order  Form 


PAU.  1000 


VIII- 1 


BA8EUNE  AS  OF:  JANUARY  20, 1003 


4.0.3 


OM  NUMBER 


oSfTaSuMBnlnSNCONMWTION 


Am.  9/10/90 

DATE  SUBMITTED 


-  ASCX12 

WORK  REQUEST  FORM 


(Secretariat  Only) 


AU.  REQUESTS  MUST  BE  TYPED  or  printed  legibly  in  black  Ink.  Complete  both  side*. 


1.  TO  USE  THIS  FOAM  FOP  SUPPOPTINO  QATAMUNTENANCE  POP  A  N6WDPAFT  STANOAPD  OPX12  INTERPRETATION,  Sa*  al 
raoutramem  on  ONE  form.  m#  attachments  m  ninaiairy.  Uet  Aral  a*  new  segmentt.  ften  el  naw  data  aiomanta/eedee/eode  source*. 
Then  Hat  revisions  to  ousting  aagmanta  and  date  aiamants/eodsa/codn  sources.  Than  Hal  any  aetata  (e  g-  X12A  X124). 


1  TO  USE  THIS  FORM  TO  REQUEST  A  CHANGE  TO  AN  P0STXO  STANDARD.  uae  a  aaporaas  WNt»  Paquaal  Farm  to  Mat  all  ehangea  tor 
one  iranaanten  att  one  aeynent  one  parted  wructuro,  at  one  data  atsmant  AS  aaedena  mud  be  oompiotsd.  Attadtmenta  may  be  weed 
ter  continuation  and  should  be  numbered. 

3.  TO  USE  THIS  FORM  TO  REQUEST  A  PROPOSED  NEW  XU  PROJECT,  eomptata  Section  A.  Provide  a  purpoee/aoope  and  deaeribe  any 
new  feaurea  involved  in  Section  8.  Provide  a  doacrtpdonorstotuainoaa  need  and  juaWicotion  tor  dte  new  project  In  Section  C/Pdt«.  The 
Wore  Baqueat  wf  be  lotwatded  to  an  approprtata  X12  aubeommiaea  tor  anatyats  and  propardlon  ot  a  protect  proposal. 

Circle  One:  (1)  Now  Standard  Supporting  Data  Maintenance  (uaa  attachmanta) 

(2)  Existing  Standard  Maintenance  Request  (saa  Section  D) 

(3)  Request  for  New  XI 2  Project 


Acronyme/abbreviabona  cannot  bo  addad  to  fte  atandarda.  hduetryepeelttc  tarma  muat  be  daarty  aaptamed.  Provide  Appendia  A  code 
aoutoe  relerencea  tor  ai  artamdfr  putifcahad  node  law  chad.  Dtoompieta  terms  or  dtoao  adh  madequaw  aupport  tor  tie  change  raquaaiad 
mi  bt  rttunrd  to  tot  tubrnittor. 

A.  SUBMITTER  INFORMATION 

Submitter  Name _ _ _ _ 

Company _ _ 

Address  _ _ _ 

Addrsss/ZIP 

Phone  _ 


Indicate  the  X12  subcommittee  or  task  group  whose  position  is  represented  hare. 

I  declare  that  tftis  represents  the  official  posMon  of  Xia  WORK  GROUP: _ 

established  at  the  masting  dated _ 

B.  PROPOSED  wdRK:  List  the  specific  changes  to  the  standards  being  requested.  Give  the  names  and 
associated  identifiers  of  the  standards,  segments,  data  elements  and  codes  affected. 


44.4 


BASEUNE  AS  OF:  JANUARY  2S,  IMS 


DWAimMMT  OF  MFBtSE 
ORAFT  MPLEMCMTAT10N  COMWNTION 


Parti:  List  the  version/release  of  the  standard  you  are  using  or  using  as  a  reference.  Name  ths  transaction  set 
that  la  belng/wW  ba  used  that  dlctatas  tha  requested  changed.  List  affected  segments  and  data  elements,  or 
othar  standards.  Provide  only  reference  numbars/lOa. 


Rafaranea  Sourca  Varsion  2/Raiaasa _ 

Transaction  Sat  Usad  _ 

Segment  Affactad  _ 

Data  Elamant  Affactad _ 

Othar  Standard _ 

Part  II:  Explain  why  you  naad  tha  propoaad  changa.  Provide  a  complete  scenario  that  tals  what  the  business 
function,  operation,  or  problem  is  that  wff  ba  satisfied  by  a  change  to  tha  standard.  The  XtZJ  Technical 
Assessment  Subcommittee  requires  enough  Information  in  this  Part  It  to  ba  able  to  propose  an  altamata  solution  V 
necessary. 


0.  RAMIFICATIONS:  If  you  circled  (2)  on  Page  t,  complete  this  section.  To  ensure  that  afi  ramWcadons  of  your 
proposed  change  are  recorded  and  that  your  request  Is  complete,  circle  batowal  sections  of  the  standards 
affactad  by  tha  proposed  change. 


TRANSACTION  SET 


SEGMENT 


DATA  ELEMENT 


Purpeae/Seaea 


i  Now /Comment 


MSOC 


Ream  Noe  Swnenec 


Type 


Mn/Ma* 


Oaoaoa  Cads 


Coda 


COOE  A 

OTHER  (e.g..  X12.5.  X12.6): 

ERRORS  NOTED  IN  THE  STANOARO  (GNe  page  no.  and  other  tdentfflcation): 


BASCUNC  AS  OF:  JANUARY  »,  MU 


4.0.S 


»  ,  J 


PP  No. 


«•*.  4/1/80 


(Secretariat  Only) 


ASC  X12 

NEW  PROJECT  PROPOSAL  FORM 


PROCEDURE:  Only  XI 2  subcommittees  may  use  this  form  to  register  new  development  activities  as  X12  project 
proposals  (PPs).  Complete  all  pages.  PPs  approved  by  the  X12  Procedures  Review  Board  will  be  registered  and 
assigned  a  PP  number  by  DISA,  and  a  Transmittal  Form  wil  be  issued. 

Date  and  complete  the  form  below.  Type  or  print  legibly  in  black  ink  and  number  alt  attachment  pages 
consecutively.  Submit  to  DISA  prior  to  an  ASC  X12  meeting,  or  to  X12J  Technical  Assessment  Subcommittee 
during  the  subcommittee's  agenda  period  at  an  ASC  XI 2  meeting. 


Date  Submitted: 

Date  Approved  by  Subcommittee: 

Subcommittee  Name: 

Task  Group  Name/No.: 

Joint  Development  Subcommittee  (H  any): 

Circle  one:  (a)  Transaction  Sat  (b)  Guideline  (c)  Other 

Project  Working  Title: 


Official  Oelegate(s)  for  This  Project  To  Be  Named  on  Transmittal  Form: 


Name 


Name 


Company 


Company 


Address 


Address 


Address/ZIP 


_Address/2P 


Telephone 


.Telephone 


BA8EUNE  AS  OS:  JANUARY  28, 1893 


O&ARTMOfT  Of  DEFENSE 
DRAFT  ttFimCNTATION  CONVBfTlON 


A.  PURPOSE  AMO  SCOPE  FOR  THE  PROPOSED  WORK:  Provide  a  wen-defined  purpose/scope  form# 
proposed  wortc.  See  X12  Design  Rifes  and  GuidsUnee  for  requirements. 


B.  BACKGROUND:  Provide  detala  ttm  w*  be  heipM  In  reviewing  the  proposal.  Who  are  the  expected  users? 
How  *■  the  standard  be  used?  What  business  functions)  does  K  serve?.  If  the  proposed  standard  overlaps  the 
functionality  of  an  existing  Mandat'd  or  one  In  ctareiopment,  provide  lusdflestton.  If  the  proposal  Is  not  tor  a  now 
standard  or  guideline,  describe  the  protect  to  data!.  (Use  attachments  *  necessary.) 


6.  6tHER  STANDARDS  mvdtVEb:  H  applicable.  Identify  any  ocher  business  Mormetion  standards  that  are 
simlar/ralatad  to  the  proposal,  and  name  standards  developers  (e.g.,  ANSI  Aceredted  Standards  Commtoees) 
whose  activities  may  be  Involved  or  affected. 


0.  EXPECTED  CONTENT /GENERAL  DCSCRJTbON:  (OPTIONAL)  Submater  may  attach  a  preliminary  draft  of 
the  proposed  standard  or  other  supporting  documentation.  Discuss  new  segments,  data  elements,  control 
structures,  and  changes  to  X124  or  Xl2.6thsl  are  required  or  anticipated.  (Use  attachments.) 


•AMUNB  AS  OF:  JANUARY  2S,  ISM 


DEPARTMENT  OP  DEFENSE 

DRAFT  MPLEMEMTAT10N  CONVENTION 


FORM  FOR  NEW  OR  REVISED 
APPENDIX  A  CODE  SOURCE  REFERENCE 

INSTRUCTIONS:  Complete  this  form  whenever  a  new  data  element  or  data  element  code  It  requested  to  be 
added  which  references  a  code  list  published  by  an  external  (non-Xi2)  organization.  Use  one  form  for  each  new 
reference.  This  form  may  be  used  to  revise  current  references:  fBI  out  the  appropriate  areas  below. 


CIRCLE  ONE,  COMPLETE  AS  APPROPRIATE: 

(1)  NEW  REFERENCE 

(2)  REVISED  REFERENCE.  Current  reference  number/name _ ; _ 

REFERENCE  TITLE:  If  there  is  only  one  source  for  codes  for  the  data  element,  the  title  should  be  the  same  as  the 
data  element  name.  If  there  are  multiple  codes  referencing  external  code  sources  for  the  same  data  element.  title 
should  approximate  the  code  definition. 

REFERENCE  TITLE: 


DATA  ELEMENTS  USEO  IN:  Give  the  data  element  reference  number  and  name  which  directs  the  user  to  this 
Appendix  A  code  source  reference.  Give  the  code  ID  (V  assigned)  If  this  Is  for  a  specific  code  of  the  data  elemett. 

USED  IN:  DE  No. _ .  Code  ID _ 

SOURCE:  Provide  the  name  of  the  publication  which  contains  the  codes  referenced 
PUBUSHED  IN: 

AVAILABLE  FROM:  Give  the  publisher,  or  other  contact,  from  whom  the  user  can  obtain  the  document. 

Name/Attn  of  __________________________________________ 

Company _ 

Address _ 

Address  _ 

Address/ZIP  _ 

ABSTRACT:  Briefly  describe  the  publication,  Its  purpose,  and  indicate  what  codes  It  contains. 

ABSTRACT: 


4A.S 


BASEUNE  AS  OP:  JANUARY  2*.  1SS3 


DEPARTMENT  Of  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


DOCUMENT  PREPARATION  FOR 
INTERPRETATIONS,  GUIDELINES  AND  CONTROL  STANDARDS 


«/v» 


That#  instructions  art  provided  to  assist  dsv  elopers  of  Interpretations,  guidelines  and  control  structura  which  art 
not  transaction  sats  (for  transaction  sat s  usa  tha  Naw  Transaction  Sat  Oavalopmant  Form). 

GENERAL:  DISA  provides  tMa  paga  and  front  matt ar  for  publications  and  copyadlts  tha  doeumant  according  to 
DISA  housa  styta. 

REVISIONS:  If  tha  doeumant  is  a  ravlsion  of  a  pravtousfy  publishad  Interpretation,  guldalina  or  standard,  provide  a 
summary  of  tha  changes  to  the  original  that  art  contalnad  in  tha  doeumant 

I  INTERPRETATIONS 

A  formal  Intarpratation  of  an  XI 2™  Standard  la  considered  part  of  tha  body  of  standards  whan  t  la  approved  for 
publication.  The  Interpretation  draft  should  state  the  issue  presented  by  the  requestor,  state  the  proposed 
Interpretation,  and  show  as  attachments  any  Work  Requests  that  may  be  necessary  to  effect  the  Intarpratation 
within  tha  subject  standard.  The  draft  interpretation  fa  processed  lice  any  other  subcommittee  document 

II  GUIDELINES 

For  publication  purposes,  guidelines  are  traatsdHke  a  journal  article.  Basic  requirements  are  given  below. 

ABSTRACT:  This  is  a  precise  summary  of  the  Purpose/Scope  (see  below),  and  may  be  Identical  to  ft  I  that  Is  brief 
(two  paragraphs);  otherwise  summarize  the  purpoee/scope.  It  shotM  contain  enough  Information  about  the 
document  to  enabie  a  reader  determine  what  the  guideline  Is  Intended  to  accomplish  vrtthln  an  EDI  environment 

PURPOSE  ANO  SCOPE:  This  statement  must  Indicate  purpose  of  the  gukfeftne.  e.g.,  the  business  function  or 
operation  addressed.  Scope  and  any  specfllc  flmfcatione  of  scope  shoUd  be  defined. 

BODY  Of  TEXT:  This  may  bea  number  of  subsections  logicaly  organized.  Provide  sections  lor  foreword, 
introduction,  definition  of  terms  and  concepts,  references  and  related  standards,  methodology.  spedftcatione. 
requirements,  discussion,  and  conclusions,  as  appropriate  to  tha  subject 

ART  AND  GRAPHICS:  Graphics  or  artwork  necessary  to  Bustrate  the  document  are  encouraged.  Provide 
camera-ready  copy  if  these  are  not  already  prepared  and  delivered  on  a  WP  diskette  to  DISA. 

FOREWORD,  FOOTNOTES,  APPENDICES:  These  may  be  used  for  purposes  of  deity,  lustration,  or  general 
information,  not  as ‘part  of  the  guideline.  ‘  A  statement  Indicating  the  material  is  for  information  purposes  only  and 
not  part  of  the  guideline  she!  appear  at  the  beginning  of  a  foreword  or  appendbc 

III  CONTROL  STRUCTURES  AND  OTHER  STANDARDS 

For  publication  purposes,  these  documents  are  treated  Hire  guidelines  (see  Section  II  above).  The  requirements  are 
the  same,  with  tha  addition  of  tha  folowing: 

NEW  SEGMENTS  AND  DATA  ELEMENTS:  These  may  be  defined  within  the  text,  however,  since  they  represent 
changes  to  Xt  2.22  and  Xl  2.3,  they  shodd  be  specified  on  a  Work  Request  Form  attached  to  the  draft. 

RELATED  X12™  STANDARDS  AND  OTHER  REFERENCES:  These  sftal  be  Identified  m  a  section  wtthin  the  taxL 


BASEUNE  AS  OF:  JANUARY  29, 1993 


DEPARTMENT  Of  09B4SE 

DRAFT  MPtEMENTATION  CONVENTION 


PRO*  Two 

FORMAT.  Tha  Draft  Standard  tor  Trtai  Um  contains  tha  format  and  sstabftshaa  tha  data  contorts  of  tha 

_ Tramacdon  Sat  ( _ )  tor  uaa  wfthln  tha  contact  of  an  Elactronic  Data  Intarehangt  (EDI) 

anvtronmant.  Tha  transaction  sat  (can  bo  uaad  to...)* 


C.  PURPOSE  AND  SCORE  ThS  atatamant  muat  Indlcata  tha  M  anga  of  capabWaa  of  tha  tranaacdon  tat  and 
who  tha  aandara/racaNart  ara.  Explain  tha  buainaaa  function  or  opanttonthat  la  addraaaad.  FolowASCXi2 
OaaignRtAaa  and  GuidaNnaa  ant  um  thM  tarmac 

FORMAT:  Tha  standard  pnatdaa  tha  format  and  aatatallshaa  tha  data  oontanta  of  tha _ Tranaacdon 

Sot  within  tha  context  of  an  Electronic  Data  interchange  (EOi)  environment  Tha  tranaacdon  Mt  (can  ba  used  to...)* 


D.'TlUN&Adti6N $£t fA9LI(i)  far  each 55a preside tha 5KKgBBnw55»T  TOWmaT 

TABLE  X 


POSITION  SEGMENT  REQ.  MAX. 

H£j ID  TITLE _ DESl.USRl 

010  ST  Transaction  Sat  Haadar  M  1 
020  BB  Baginning  Sagsant  For  M  1 
ate. 


LOOP  REPEAT  NOTE 


REE- 
Noto  1 
Coaaant  1 


Natal:  TNabanota.  NOTES  ara  part  of  tha  standard  (numborad). 

Commert  A:  Tha  a  a  comment  COMMENTSarenot  part  of  the  standard  Pattered). 


C  A^pfaotx  EXAMFLE1  fcamplasars  uaad  to  test  the  mart  of  the  proposed  tranaacdon  and  to  explain!  to 
users.  At  laaat  ona  example  S  mandatory.  No  tacogntraWa  propar  namaa  may  ba  uaad  in  any  aorampla. 

FIGURE  l:  (Optional)  Uaa  a  aampla  papar  documant  using  mock  da*.  If  uaad,  data  mist  ba  accuratsfy  mapped 
toF)gura2.  Original grapMea muat ba attachod (9>i/2xiV) aothay eon be  copied. 

FIGURE  2  (or  EXAMPLE):  TMa  tha  Rgura  and  provida  a  Buainaaa  Seanarto  to  axplain  to  tha  raadar  what  Is  going 
onlntheaarampto.  Addthanota:  Tn  this  axantpla  tha  aatartafc(*)tapraaania  tha  data  otomantaopaiator  and  tha 
N/lcharactsrsraprasant  the  segment  terminator.*  Praaant  EDI  transmission  data  and  la  meaning  in  two  coMwna. 
aide-by-side.  ZZ  or  HZ  codes  are  dtocouraged,  Snce  their  ueehinesa  In  an  explanatory  asample  a  nl.  FORMAT: 

BUSINESS  SCENARIO:  In  thla  ttanaacdon  aat  tha  aandar  la  XYZ  Ratal  Cantar  and  tha  tocaNar  la  thalr  auppUar. 
Fantastic  Product!  MamAacturtng.  Inc. ..ate. 

EDI  TRANSMISSION  DATA _ (TTWiSACTlQMSET  PUflPQSBLPftlA. 

ST*9XX*0005  N/L  Begin  Transaction  Sat  SXX;  Control 

NO.  0005 

88*01*79900*  N/L  Original  Transmission;  Raf.  No. 

79900 

stc. 
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9/10/90 

DM  Number _ 

(Secretariat  Only) 

OocumoniNo. _ 

(Developer  Obtains  from  DlSA) 


ASC  X12 

NEW  TRANSACTION  SET  DEVELOPMENT  FORM 


INSTRUCTIONS:  Use  this  form  to  submit  e  draft  transection  set  for  review  by  X12J  Technical  Assessment  untl  k  is 
text  processed  by  DlSA.  Use  a  new  Transaction  Set  Development  Form  whenever  revisions  are  propoeed  and  a 
text  He  has  not  yet  been  prepared  by  DlSA. 

ATTACHMENTS:  Attach  aR  peges;  use  this  form  as  the  first.  Follow  theee  Instructions  for  preparing  materials. 

The  submkter  must  obtain  a  document  number  assignment  from  DlSA.  Poet  k  to  this  form  (above). 

Attach  a  List  of  Revisions  If  the  draft  was  previously  reviawad  by  X12J  or  R  this  is  a  ravtsad/redesignad 
transaction  set  standard  requiring  X12  balot 

Use  ONE  Work  Request  Form  to  list  el  supporting  data  maintenance  for  the  transaction  sat  and  attach  k 
to  this  form.  Propose  naw  or  revised  codes  for  OE 143  and  DE  479  at  a  minimum.  Inquired. 

A  Transmittal  Form  must  accompany  this  document  when  k  is  submkted  to  DlSA  for  dlstrtxJdon. 

Use  the  most  recent  X12™  Standards  Development  Workbook  to  check  your  document  for  accuracy. 

A.  SUBMITTER  INFORMATION 
Submitter:  Name 


Company 

Address 


Address/ZIP 

Phone 


Indicate  the  Xt2  subcommittee  or  task  group  whose  position  Is  represented  here. 
I  declare  that  this  represents  the  official  position  of  X12  WORK  GROUP: 
established  at  the  meeting  dated _ . 


B.  ABSTRACT  The  Abstract  Is  registered  with  the  American  National  Standards  Institute.  It  is  a  precise  summary 
of  the  Purpose/Scope  (see  Section  C  below).  It  may  be  Identical  to  the  Purpoee/Scope  R  that  b  brief  (two 
paragraphs),  otherwise  summarize  the  purpoee/scope.  It  should  contain  enough  Information  about  the  starxlard 
to  enable  a  potential  user  determine  what  equivalent  paper  transaction  k  represents  or  what  the  standard  is 
intended  to  do.  Follow  the  format  on  page  two. 


BASEUNE  AS  OF:  JANUARY  29, 1993 
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SAMPLE  TRANSMITTAL  FORM 


.  3/10/90 


initialized 
KEY  DATE:  February  IS,  1990 

DELEGATES  NAME 
RESPONSIBLE  SUBCOMMITTEE/TG# 

TRANSACTION  SET/GUIDEUNE  TITLE 

BALLOT  Document  No. 

Current  Document  No. 

Previous  Document  No. 

Project  Proposal  No. 

Associated  WR/DM  No. 


John  Doe 

ASC  Xi  20  XX  Subcommittee /TG4 
X12J0C  ABC/XYZ  TRANSACTION  SET  (CXX) 


ASC  X120/90-051 
ASC  XI 20/90-004 
PP-999 
DM  012-190 


PROJECT  PROPOSAL 
PP  Review  by  X12J 
PRB  Approves  PP 

DEVELOPMENT  PHASE:  Project  proposal  approval  through  approval  for  XI 2  vote. 

Document  Submitted  for  DISA  Text  Processing 

Subcommittee  Approves  Draft  for  Review  by  X12J,  Tech  Assessment 

X12J  Tech  Assessment  Review 

PRB  Approves  Document  for  XI 2  Vote 


ORIGINAL  BALLOT  DATA  (DISA): 

Ballot  Closed  Date 

Tally /Comments  Sent  to  Chair /Delegates 
Tally  Stats  (Number  and  Percent) 

_ Ballots  Mated  (100%) 

_ Ballots  Returned  ( _ %) 

_ Approved  ( _ %) 

_ Appw/Comment  ( _ %) 

_ Disapproved  ( _ %) 

_ Abstained  ( _ %) 


(DATE)  2/7/90 
(DATE)  2/9/90 


(DATE). 

(DATE) 

PATE). 

PATE) 


PATE). 

PATE). 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


Pag*  Two 

COMMENT  RESOLUTION  PHASE:  Saa  Sections  A,  B  and  C.  If  th*  subcommKtM  at  any  tima  daddM  to  rabidiat 
tha  document,  PRB  approval  Is  raqulrad  and  response  letters  ar*  not  nacaaaary. 

A.  COMMENT  RESPONSE  LETTERS:  An  Opan  Forum  must  ba  schediled  at  the  next  X12  meeting  following  the 
balot  dosing  date.  Al  those  who  commented  receive  a  comment  response  letter  from  the  developing 
subcommittee.  OISA  records  this  process  and  hands*  the  mallng. 


Open  Foium  Date  (DATE) 

Response  Letters  Maled  Out  by  DISA  (DATE) 

Rebuttal  Period  (30  days)  Closes  (DATE) 


ADJUSTED  BALLOT  DATA  (DISA): 

30-0ay  Response  Review  Closed  Date  (DATE) 

Taly/Commenu  Sent  to  Chalr/Delegates  (DATE) 


Taiy  Stats  (Number  and  Percent) 

_ Balou  Maled  (100*) 

_ Balou  Returned  ( _ %) 

_ Approved  ( _ *) 

_ Appw/Comment  ( _ *) 

_ Disapproved  ( _ *) 

_ Abstained  ( _ %) 


B.  SUBSTANTIVE  REVISION:  If  balot  comments  result  In  substantive  revisions  to  the  document,  these  are 
reviewed  by  X12J  and  processed  by  OISA  The  revised  document  is  submtted  to  X12  voters  for  a  30-day  review 
period.  DISA  records  this  procaes/handles  mallng.  Subcommittees  shotid  conduct  30-day  reviews  for  response 
letters/revised  documents  concurrently. 


Subcommittee  Approval  of  Revisions  (DATE) 

X12J  Review  of  Revisions  (DATE) 

PISA  Mala  Revised  Document  (DATE) 

Substantive  Revision  30-Day  Review  Coses  (DATE) 


ADJUSTED  BALLOT  DATA  (DISA): 

30-Oay  Substantive  Change  Review  Cosed  Date  (DATE) 

Taly/Comments  Sent  to  Chair /Delegates  (DATE) 


Taly  Stats  (Number  and  Percent) 

_ Balou  Maled  (100%) 

_ Balou  Returned  ( _ *) 

_ Approved  (__%) 

_ Appw/Comment  ( _ %) 

_ Disapproved  ( _ %) 

_ Abstained  ( _ %) 


BASELINE  AS  OF:  JANUARY  29, 1993 
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DEPARTMENT  Of  DEFENSE 

DRAFT  MPLEMCNTATION  CONVBfTION 


Page  Three 

C.  CONTINUING  OBJECTIONS.  If  there  are  continuing  disapprovals  after  the  30-day  review  period,  the 
document /disapprovals/responses/continuing  objections  are  maled  to  XI 2  members  who  originally  cast  a  ballot, 
for  another  30-day  review,  to  give  them  an  opportunity  to  change  their  vote. 

Continuing  Objections  Mated  to  Chair/Delegate  by  DISA  {DATE} _ 

DISA  Mats  Documents  (DATE) _ 

30-Day  Review  Closes  (DATE) _ 

FINAL  ADJUSTED  TALLY  (DISA);  Whenever  any  disapprovals  are  withdrawn,  a  tetter  to  this  effect  must  be 
received  in  writing  by  DISA 

Final  Tally  Results  Sent  to  Chair/Delegate  PATE) _ 

30-Day  Review  Stats  (Adjusted  Tally) 

_ Ballots  Mated  (100%) 

_ Ballou  Returned  ( _ %) 

_ Approved  ( _ ,%) 

_ Appw/Comment  ( _ %) 

_ Disapproved  ( _ %) 

_ Abstained  ( _ %) 


PRB  APPROVAL  PHASE:  After  the  comment  resolution  period,  the  subcommittee  votes  to  submit  the  document 
to  the  PRB  for  approval  to  publish. 

Subcommittee  Votes  to  Release  to  PRB 
PRB  Approves  Publication 


FOR  DRAFT  STANDARDS  FOR  TRIAL  USE: 
VERSION/RELEASE/SUBRELEASE  ID  COOE  ASSIGNED: 


(DATE) 

(DATE) 
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TRANSMITTAL  FORM  INSTRUCTIONS: 

GENERAL:  Thla  TranemBtai  Form  it  a  TURNAROUND  DOCUMENT  which  records  the  history /currant  statu*  of  a 
projec*  document.  I!  la  uMd  to  exchange  Information  between  the  Secretariat  and  the  commit#**  of  X12. 
Mormetion  to  curniadve  (add  on).  This  tom  la  attached  to  the  documant  whenever  t  la  tosued  lor  dlatribuUon  (k  la 
mandatory  tor  aubmlttlnq  documents  to  OlSA.  X12J  Technical  Aaaaaamant.  and  tha  FR8).  Docunent  control 
numbers  an  ats  required  on  each  document,  and  new  numbers  art  raqulrad  whenever  I  la  rariaad. 

KEY  DATE:  Thie  la  used  to  idenMfy  tha  lataat  varaton  of  tha  documant  (data  tasodatad  with  tha  currant  oanamBat 
form  update). 


DELEGATE:  Each  suboommEtae  designates  an  IndMdual  (dalagata)  from  tha  grtxyrsaponetolatarthaprojsct- 
Tha  Secretariat  muat  ba  Wormed  *  tha  daiegatt  changes. 

IWTUTION:  Primary  data  la  recorded  by  DISA  on  tha  Ntttead  term  altar  tha  project  propoaal  la  approved  by  tha 
PRB.  Tha  aubcommlBaa  chair  and  dalsqMc(s)  rscefre  tha  IntlaltMd  TranamMat  Form  trom  PISA;  tharaattar.  they 
are  rsaponatoia  lor  recotdtoq  the  appropriate  subcommittee  approval  dates.  Tha  chafr/rtatapata  W  receive  a  copy 
ct  tha  updated  tranamBal  term  amsnevar  t  la  rtodasd  by  OISA. 

UPDATING:  At  each  appropriate  step.  OISA  wdi  POST  trash  data  to  the  farm.  ADO  the  iwad  appropriate  blanks  to 
tha  form,  and  SEND  I  to  the  auboommttee  chafr/datogata  at  aach  atatua  change.  Tha  datagata  muat  POST  tha 
farm  wth  traeh  data  at  aach  stotua  change  tor  eMch  the  subcommtoee  to  raeponafcle  and  SEND  k  wfth  the 
appropriate  document  to  tha  Secretariat. 
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ASC  XI 2  BALLOT  COMMENT 
RESPONSE  LETTER  FORMAT 


aetCRAL  MPOMUTION 


AFTER  AN X1SBAU0T,  THE  RMPON9IBIS  SUSCOMISTTEE (OR  ITS  OEMNATSD  TASK  OROUP)  MUST  rnapond  h  wMng  MM 
The  O^angaPan  A  ftroaedumi  manual  (PPM)  amm*  tat  you  era  net  laquaad  M  raepand  id  tioaa  mambait  aha 

®«n¥TWnc,  M  9PCH)r  tf  vDfTWTWiSrV  a? w  •vtROnOBQ  t§,  I  n|  UrK  MM  IW  M  QDHWWJra  fMpQnMS  fflUBl  09  QDOWHQ 


Thar*  mwin 
mpgnNBMdi 


r  «Moh  «■  b*  mm  m  Ml 


OPTION  1:  OEMERtt  LETTER  (MASTER  LETTER)  TO  AU.  OOMMENTORS 
Youmay  prepare  on*  too*  Mb*  eantBatoommaman  Erery  aommant  laoenmc 
Mma.  nama  tm  ocrernoiaar  (XU  mamb*f  aompany  name)and9mtmmmoaid*dl 
nheaa*  taa  opaon.  you  nay  graup  tmoammenmamichamaimlirandiaapendM 


ml  Ufitymamapi 
aa  a  group  Erery 


OPTIONS:  MOMOUAL  LETTER  TO  EACH  QOMMEMTOA 

You  may  prepare  on*  ladar  Mr  aadioommanmr  If  you  ahaaae  94a  apian,  you  need  net 

F*«o»  am  uaual  buamaa*  MMr  «yM  and  *ta  general  Meaueaen*  beta*.  Erery  member 


MvmucnoMi 


•Wl:  PMnm  print  tie  tret  page  el  yataMaarfa)  on  ASC  X12 


tyau  dam  have 


Mryatrt 


tarn  Pm 

MnaakNMffa). 


•TVS:  Cal  Vta  SaenMahai  Mr  a  a 
»  yau  rend  an  MdMduolaod  Mnv  ■ 
(a.p.ASCXUF/TOamo-iaOALM* 


STEPS:  Chaeaa yaur MPar 


t  rental  number.  Thia  rembar  mm  appaar  In  Ma  upper  rtghl 
ammenmi.  ft*  deoMmantoaneal  number  realgnad  Mr  Me  tret 
*ya*r  <*.g..  asc  xtaRTOMO-tsos).  **. 


’PPw  Mai 
■d  a*  loam 


a  of  Pit  Mi 

byan'A' 


STEP  4:  Prepare  tie  MS*  MSwmng«mauRna.heMaruoing  a  typMalbMeoie*aSdeHBnwat. 

a-  ProtnaoaoBnmctnamo(*ondora)lntiouppornRitoBmoiba*a«tiemaBho*d;includaph 
b  Pm*  Pie  document aanaal number  under  •»  Moorhead bo*, 
c.  Pm*  tmdaM  under  tmdaoumonteanoal  number. 

4  APP*a*PMMSrM#»inrfMduN.arMra#*naiteMSBraafcid*anad***aa*ln*and»aN 
•  InaMdi  an  biaeduemgi  paregrephooguoMauitio  prepare  IdonOtodM  Mo  ddireoooe. 

I.  You  may  aMftmraoapfia  balat  Mly  (tarn  your  TranamiM  Farm)  Nr  maMMunaPan  at  Pta 


phono  number. 


STEP  4:  Fanamd  RaMsaraMfwSaeraMrMi.AMnaonEaaraMrMiEaruMaa.au>  a  apaar  Ml 
Maarto  you  have  prepared.  Whan  tta  MPara  here  baan  StaMmadL  P»  prapa  deMgem  and 
Tranammal  Form  wtren  haa  N  mating  data  and  SO  Pay  rnvmm  parted  doaatg  dam  pomad. 


Xt2  ladphaad  SampM 
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DATA  INTERCHANGE  [EDI] 


Tub  Jooescy 
(999)999-9999 


Accrectted  Standards  Commute 
ooenRjng  jw  uw  procedures  of  tne 
Amercen  National  Standards  institute 


Dan  Smithey 
(999)999-9999 


Document  No 

ASC  X12C/TG20/90-999 
June  25, 1990 


TO*.  X12  Members  Who  Commented  on  Modifications  to 

X12jct  Control  Structures 

RE:  Response  to  Comments  on  December  Ballot 

DMs  205289, 215289, 317289 


Thank  you  for  your  comments.  This  ballot  involved  modifications  to  XU  a  Of  the  327  ballots  mailed,  153  ballots  were 
returned.  Of  these,  81  approved.  15  approved  with  comment.  20  disapproved  with  comment  and  37  abstained. 

in  pmi  the  ot  the  ■uytifiratinan  The  maiority  of  the  comments  focused  on  the  impact 

nt  itiw  modifications  ,h*  presentation  of  information  ■■  »*«*  Dwegnwy  The  proposed  modifications 

—d  tlx-  resulting  '» haw>  been  reworked  ■  rnpnnir  ta  tW«t  mmmnnlt  A  revised 

modification  to  X12jg  was  reviewed  by  Technical  Assessment  at  the  June  ASC  X12  meeting.  Modifications  to  the 
document  have  been  made  which  reflect  responses  to  the  comments  from  this  ballot,  and  a  revised  copy  of  X12j»  is 
being  distributed  to  all  who  voted  on  this  issue,  for  30-day  review  of  revisions. 

Specific  responses  to  comments  follow. 


COMMENT:  Automobile  Corporation 

“Add  the  following  note  to  Paragraph  33:  NOTE:  Communication  protocol  characters  should  be  excluded  from  the 
sec* 

RESPONSE: 

The  cover  letter  seat  out  with  the  voting  package  explained  that  the  intent  wa»  to  obtain  consensus  on  the  proposed 
modifications  to  X12jcl  X12jb  is  a  difficult  standard  to  amend.  We  request  that  ballot  responses  be  considered  on  the 
merits  of  the  recommended  modifications  and  not  on  the  standard  as  a  whole.  Your  comment  was  outside  the  scope  of 
the  requested  modifications. 
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COMMENT:  Airoift  Engine  Corporation 

"Some  consideration  for  Abstract  Syntax  Notation  One  (ASN.l)  should  be  allowed. 

1.  ASN.l  is  capable  of  defining  all  of  the  necessary  inter-relations  needed  by  X12  transactions. 

1  ASN.l  requires  leas  characters  to  define  the  same  information. 

3.  ASN.l  is  the  encoding  scheme  used  by  most  OSI  work.' 

RESPONSE: 

The  recommendation  to  consider  usage  of  ASN.l  encoding  reaches  far  beyond  the  scope  of  the  requested 

in  this  ballot.  Activities  such  as  this  are  best  submitted  as  separate  work  requests. 

COMMENT:  Some  Software  lac 

*  Conditionality  of  data  elements  should  be  left  to  the  discretion  of  ™  plemeutation  guidelines  and  apeemencs.  There  is 
mudi  discussion  at  times  as  far  as  whether  certain  data  elements  thnuld  be  »  not;  many  ipp»i«-»ri«. 

are  incapable  of  providing  certain  'mandatory1  information  and,  as  ««<*,  filler-type  data  must  be  inserted.* 

RESPONSE: 

The  issue  of  data  clement  conditionality  as  a  whole  is  a  much  twoxtw  mhfrpt  than  — «  ■—« —M  be  -nt- 

the  scope  of  this  ballot.  This  ballot  was  intended  to  provide  ,  - ; - 

aitttdy  existing  conditional  structures.  If  the  commentor  believes  that  the  cooditaooal  structure  should  be  removed  tram 
the  standard,  the  task  group  recommends  that  this  be  submitted  as  a  separate  work  request. 

Ecc. 
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AccrwKad  Standards  Commoae  I*  Somebody 

operating  under  the  proctaw  a t  tfw  Ci««r  TG19,  XI2C 

Amerean  Natarwi  Standards  nstituta  (999)  999-9999 

Document  No 

ASCX12C/TG8/9D-99SA 
August  10, 1990 

Ml  Jaae  Doc 
Americas  Bask 
Owe  Central  Plaza 
Middle  America,  MO  99999 

RE:  Respoase  to  Commeau  oa 
ASC  XU  Model  Guideline 

Dear  Ml  Doe: 

Sahttweittr*  X12C  ha»  empowered  its  Tsak  Group  19  to  provide  reapoaaee  to  tbc  commeati  oa  this  ballot  The 
aMmbenofTC19  wish  to  thaak  all  X12  members  who  took  the  tiawm^  effort  to  vote  aathnfaidefiae.  We 
especially  thaak  each  individual  who  provided  comments,  whether  ia  approval  or  disapproval  of  the  gudebae.  We 
reeogais  aad  appreciate  year  careful  review  of  this  docuaeaL 

Oar  respoose  is  keyed  to  the  aombered  items  ia  the  commeats  attached  to  yoor  ballot. 

RESPONSE 

L  We  agree  with  yoor  oommeat.  Ia  Sectioe  4JL2,  we  haw  replaced  **c  uti£»  niies  with  'rules  _  are  utilized'. 

1  The  coataioa  between  Secriaa  4 23  aad  Sectioa  62  oaly  easts  became  of  the  example  we  chose  ia  the  fint 
secrioa.  This  is  a  hypothetical  example,  of  a  simplified  model  Header*  aad  trailers  caa  be  placed  oa  the  coateat  at 
ALL  levels,  aad  do  aot  necessarily  oorrespoad  to  ASC  XI2  headers  aad  traders. 

3.  We  agree  with  your  comment.  Srrrinn  fi  T  hit  him  rhingril  it  that  *thr  nriHishairat  nf  *  ~m  siHrrf  it  int 
1  aad  4. 
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5.0  GLOSSARY 

This  chapter  contains  ASC  X12  and  DoD  specific  glossaries. 

5.1  X12  GLOSSARY 

ANSI 

American  National  Standards  Institute 
ANSI  Standard 

A  document  published  by  ANSI  that  has  been  approved  through 
the  consensus  process  of  public  announcement  and  review.  Each 
of  these  standards  must  have  been  developed  by  an  ANSI  commit¬ 
tee  and  must  be  revisited  by  that  committee  within  5  years  for 
update.  See  Draft  Standard  for  Trial  Use  (DSTU). 

Area  Transaction  Set 

Identifies  a  predefined  area  within  a  transaction  set  (header,  detail, 
summary)  containing  segments  and  their  various  attributes. 

ASC  X12 

Accredited  Standards  Committee,  X12  comprises  industry  mem¬ 
bers  who  create  EDI  standards  for  submission  to  ANSI  for  sub¬ 
sequent  approval  and  dissemination;  or  for  submission  to  the 
UN/ECE  for  approval  and  submission  of  UN/EDIFACT  stan-dards. 

Authentication 

A  mechanism  which  allows  the  receiver  of  an  electronic  transmis¬ 
sion  to  verify  the  sender  and  the  integrity  of  the  content  of  the 
transmission  through  the  use  of  an  electronic  “key”  or  algorithm 
which  is  shared  by  the  trading  partners.  This  is  sometimes  referred 
to  as  an  electronic  signature. 

Compliance  Checking 

A  checking  process  that  is  used  to  ensure  that  a  transmission 
complies  with  ANSI  X12  syntax  rules. 

Conditional  (C) 

A  data  element  requirement  designator  which  indicates  that  the 
presence  of  a  specified  data  element  is  dependent  on  the  value  or 
presence  of  other  data  elements  in  the  segment.  The  condition 
must  be  stated  and  must  be  computer  processable. 

Control  Segment 

A  Control  Segment  has  the  same  structure  as  a  Data  Segment  but 
is  used  for  transferring  control  information  for  grouping  data 
segments.  Control  Segments  are  Loop  Control  Segments  (LS/LE). 
Transaction  Set  Control  Segments  (ST/SE),  and  Functional  Group 
Control  Segments  (GS/GE),  defined  in  X12.6,  and  Interchange 
Control  Segments  (ISA/IEA/TA1)  defined  in  X12.5. 
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Data  Element 

The  basic  units  of  information  in  the  EDI  standards  containing  a 
set  of  values  that  represent  a  singular  fact.  They  may  be  single- 
character  codes,  literal  descriptions,  or  numeric  values. 

Data  Element  Length 

This  is  the  range,  minimum  to  maximum,  of  the  number  of  char¬ 
acter  positions  available  to  represent  the  value  of  a  data  element. 
A  data  element  may  be  of  variable  length  with  range  from  mini¬ 
mum  to  maximum,  or  it  may  be  of  fixed  length  in  which  the 
minimum  is  equal  to  the  maximum. 

Data  Element  Reference  Number 

Reference  number  assigned  to  each  data  element  as  a  unique 
identifier. 

Data  Element  Requirement  Designator 
A  code  defining  the  need  for  a  data  element  value  to  appear  in  the 
segment  if  the  segment  is  transmitted.  The  X12  codes  are  man¬ 
datory  (M),  optional  (O),  or  conditional  (C).  DoD  may  "require” 
a  segment  which  is  optional  by  X12  standards. 

Data  Element  Separator 

A  unique  character  preceding  each  data  element  that  is  used  to 
delimit  data  elements  within  a  segment.  Dod  uses  as  the 
delimiter. 

Data  Element  Type 

A  data  element  may  be  one  of  six  types:  numeric,  decimal, 
identifier,  string,  date,  or  time. 

Delimiters 

The  delimiters  consist  of  two  levels  of  separators  and  a  terminator. 
The  delimiters  are  an  integral  part  of  the  transferred  data  stream. 
Delimiters  are  specified  in  the  interchange  header  and  may  not  be 
used  in  a  data  element  value  elsewhere  in  the  interchange.  From 
highest  to  lowest  level,  the  separators  and  terminator  are  segment 
terminator  and  data  element  separator. 

DISA 

Data  Interchange  Standards  Association.  A  nonprofit  organization 
funded  by  ASC  XI 2  members  which  serves  as  the  Secretariat  for 
X12. 

DSTU 

Draft  Standard  for  Trial  Use.  Represents  a  document  approved  for 
publication  by  the  full  X12  committee  following  membership  con¬ 
sensus  and  subsequent  resolution  of  negative  votes.  (Final  Report 
of  X12  Publications  Task  Group).  The  Draft  EDI  Standard  for 
Trial  Use  document  represents  an  ASC  X12  approved  standard  for 
use  prior  to  approval  by  ANSI.  See  ANSI  Standard. 
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EDI 

Electronic  Data  Interchange.  The  computer  application  to  com¬ 
puter  application  exchange  of  business  information  in  a  standard 
format. 

Electronic  Envelope 

Electronic  information  which  binds  together  a  set  of  transmitted 
documents  being  sent  from  one  sender  to  one  receiver. 

Element  Delimiter 

A  single-character  which  follows  the  segment  identifier  and 
separates  each  data  element  in  a  segment  except  the  last. 

Functional  Group 

A  group  of  one  or  more  transaction  sets  bounded  by  a  functional 
group  header  segment  and  a  functional  group  trailer  segment. 

Functional  Group  Segments 

GS/GE  segments  identify  a  specific  functional  group  of  documents 
such  as  purchase  orders. 

Industry  Conventions 

Defines  how  the  ASC  X12  standards  are  used  by  the  specific 
industry 

Industry  Guidelines 

Defines  the  EDI  environment  for  using  conventions  within  an 
industry.  It  provides  assistance  on  how  to  implement  X12  stand¬ 
ards. 

Interchange  Control  Segments 

ISA/IEA  segments  identify  a  unique  interchange  being  sent  from 
one  sender  to  one  receiver  (see  electronic  envelope). 

Interchange  Control  Structure 

The  interchange  header  and  trailer  segments  envelop  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions:  (1)  defines  the  data  element 
separators  and  the  data  segment  terminators,  (2)  identifies  the 
sender  and  receiver,  (3)  provides  control  information  for  the  inter¬ 
change,  and  (4)  allows  for  authorization  and  securi*y  information. 
(X12.5) 

Loop 

A  group  of  semantically  related  segments;  these  segments  may  be 
either  txiunded  or  unbounded  (X12.6).  The  N1  loop  is  an  example 
of  a  loop,  which  includes  segments  N1  to  PER  for  name  and 
address  information. 

Mandatory  (M) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element  is  required. 


Mapping 

The  process  of  identifying  the  standard  data  element’s  relationship 
•  j  application  data  elements. 

Max  Use 

Specifies  the  maximum  number  of  times  a  segment  can  be  used  at 
the  location  in  a  transaction  set 

Message 

Entire  data  stream  including  the  outer  envelope 
Optional  (O) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element/segment  is  at  the  option 
of  the  sending  party  which  can  be  based  on  the  mutual  agreement 
of  the  interchange  parties. 

Qualifier 

A  data  element  which  identifies  or  defines  a  related  element,  set 
of  elements,  or  a  segment.  The  qualifier  contains  a  code  taken 
from  a  list  of  approved  codes. 

Repeating  Segment 

A  segment  that  may  be  used  more  than  once  at  a  given  location 
in  a  transaction  set.  See  Max  Use. 

Security 

System  screening  which  denies  access  to  unauthorized  users  and 
protects  data  from  unauthorized  uses 

Segment 

Segments  consist  of  logically  related  data  elements  in  a  defined 
sequence.  A  data  segment  consists  of  a  segment  identifier,  one  or 
more  data  elements  each  preceded  by  an  element  separator,  and 
ends  with  a  segment  terminator. 

Segment  Directory 

Provides  the  purpose  and  format  of  the  segments  used  in  the 
construction  of  transaction  sets.  The  directory  lists  each  segment 
by  name,  purpose,  identifier,  the  contained  data  elements  in  the 
specified  order,  and  the  requirement  designator  for  each  data 
element. 

Segment  Identifier 

A  unique  identifier  for  a  segment  composed  of  a  combination  of 
two  or  three  upper-case  letters  and  digits.  The  segment  identifier 
occupies  the  first-character  positions  of  the  segment.  The  segment 
identifier  is  not  a  data  element.  The  segment  identifier  in 
EDIFACT  is  a  component  data  element  —  part  of  a  composite 
data  element  consisting  of  a  segment  identifier  and  an  explicit 
looping  designator. 


BASELINE  AS  OF:  JANUARY  29, 1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 

Segment  Terminator 

A  unique  character  appearing  at  the  end  of  a  segment  to  indicate 
the  termination  of  the  segment,  e.g.,  N/L. 

Syntax 

The  grammar  or  rules  which  define  the  structure  of  the  EDI 
standards  (i.e.,  the  use  of  loops,  qualifiers,  etc.).  Syntax  rules  are 
published  in  ANSI  XI  2.6. 

Transaction  Set 

The  transaction  set  unambiguously  defines,  in  the  standard  syntax, 
information  of  business  or  strategic  significance  and  consists  of  a 
transaction  set  header  segment,  one  or  more  data  segments  in  a 
specified  order,  and  a  transaction  set  trailer  segment. 

Transaction  Set  ID 

An  identifier  that  uniquely  identifies  the  transaction  set.  This 
identifier  is  the  first  data  element  of  the  transaction  set  header 
segment. 

Translation 

The  act  of  accepting  documents  in  other  than  standard  format  and 
translating  them  to  the  standard. 

Version/Release 

Identifies  the  publication  of  the  standard  being  used  for  the  genera¬ 
tion  or  the  interpretation  of  data  in  the  X12  standard  format.  May 
be  found  in  the  Functional  Group  Header  Segment  (GS)  and  in  the 
Interchange  Control  Header  Segment  (ISA).  See  Control  Segment. 

VICS  Committee 

Voluntary  Interindustry  Communications  Standards  for  Electronic 
Data  Interchange 

X12 

The  ANSI  committee  responsible  for  the  development  and  main¬ 
tenance  of  standards  for  electronic  data  interchange  (EDI). 

X12.5 

Interchange  Control  Structure.  This  standard  provides  the  inter¬ 
change  envelope  of  a  header  and  trailer  for  the  electronic  inter¬ 
change  through  a  data  transmission,  and  it  provides  a  structure  to 
acknowledge  the  receipt  and  processing  of  this  envelope. 

X12.6 

Application  Control  Structure.  This  standard  describes  the  control 
segments  used  to  envelop  loops  of  data  segments,  to  envelop 
transaction  sets,  and  to  envelop  groups  of  related  transaction  sets. 
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5.2  DoD  GLOSSARY 

AIS 

Automated  Information  Systems 
ASD(P&L) 

Assistant  Secretary  of  Defense  (Production  and  Logistics) 

DES 

Data  Encryption  Standard 
DISA 

Defense  Information  Systems  Agency 

DLA 

Defense  Logistics  Agency 
ISA 

Interchange  Control  Header  Identifier 
NIST 

National  Institute  of  Standards  and  Technology 
NTE 

Note  Identifier 
PLUS 

Protection  of  Logistics  Unclassified/Sensitive  Systems 
UN/EDIFACT 

EDIFACT;  Electronic  Data  Interchange  for  Administration,  Com¬ 
merce,  and  Transport 
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